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Requirement:  (1)  Develop  a  top-down  design  for  an  integrated  family  of 

modular  division- level  battle  simulations  which  separately  or  jointly  will 
exercise  players  performing  critical  functions  in  command  and  control  (Vol.  I) . 
(2)  Develop  detailed  design  specifications  for  the  Intelligence  Staff  module 
of  the  integrated  battle  simulation  (Volume  II). 

The  design  approach  involved  the  following  principles:  selection  of  the 
decision  variables  to  be  manipulated  by  the  division  staff  modules  (Continued) 
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.  and  the  event  threads  both  within  and  external  to  the  staff  modules  thereby 
fixing  the  event  sequence  and  time  of  occurrence;  and  incorporating  into 
the  simulation  every  event  thread  needed  to  support  the  input/output  re¬ 
lationship.  The  dynamic  realism  needed  to  place  decision  makers  in  a 
realistic  environment  is  achieved  by  means  of  an  event  store  technique. 

The  five  classes  of  events  of  which  the  event  threads  are  composed  are 
defined  and  the  logical  flow  of  the  event  store  simulation  is  illustrated. 

A  si-xth  class  of  event  needed  for  operation  in  an  ADP-assisted  mode  is 
also  defined.  The  approach  begins  at  the  heart  of  the  information  system, 
the  decisions,  and  then  develops  the  simulation  needed  to  implement  them — 
the  inverse  of  the  usual  approach. 

The  design  concept  provides  for  a  man  in  the  loop  in  that  any  one  or 
any  combination  of  five  basic  staff  modules  (Cmd  Grp,  G-2,  G-3,  G-l/G-4, 
FSCE)  plus  one  enemy  module  (Cmd  Grp)  may  be  either  occupied  by  human  play¬ 
ers  or  simulated.  The  module  simulations  are  designed  as  "plug-in"  modules 
any  one  or  more  of  which  can  be  replaced  by  players.  The  simulation  also 
contains  a  battle  outcome  generator  which  simulates  all  other  events  within 
the  division  and  the  enemy  force  opposing  it,  and  which  feeds  back  to  the 
players  in  slow,  real,  or  fast  time  (at  the  option  of  the  user)  the  results 
of  their  decisions.  The  design  also  provides  for  interfaces  with  higher 
and  adjacent  units.  It  includes  the  following  features: 

1.  The  modules  are  based  on  the  traditional  G-staff  structure. 

2.  Nuclear  battle  events  are  included. 

3.  Live  modules  may  be  required  to  perform  simultaneous  planning 
and  execution;  the  results  of  such  planning  may  be  evaluated 
by  subsequent  execution  of  plans. 

4.  Other  staff  elements  not  included  in  the  basic  five  modules 
(e.g.,  engineer,  signal)  are  "hardwired"  components  of  the 
simulation. 

5.  The  basic  design  provides  for  manual  operation  by  live  players 
but  it  is  readily  expandable  to  permit  player  operation  in  an 
ADP-assisted  mode. 
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ARI  Research  Reports  and  Technical  Reports  are  intended  for  sponsors  of 
R&D  tasks  and  for  other  research  and  military  agencies.  Any  findings  ready 
for  implementation  at  die  time  of  publication  are  presented  in  the  last  part 
of  the  Brief.  Upon  completion  of  a  major  phase  of  the  task,  formal  recom¬ 
mendations  for  official  action  normally  are  conveyed  to  appropriate  military 
agencies  by  briefing  or  Disposition  Form. 


FOREWORD 


The  Army  Research  Institite  for  the  Behavioral  and  Social  Sciences 
(ARI)  conducts  research  on  tactical  information  systems  with  particular 
emphasis  on  the  human  factor  in  battlefield  command/ control  and  intelli¬ 
gence  functions  and  operations.  The  development  and  refinement  of 
man-in-the-loop  simulations  to  serve  as  research  test-beds  is  a  necessary 
step  in  the  development  of  command  staff  aids  and  procedures  to  meet  the 
challenge  of  the  modern  battlefield.  The  ARI  research  program  in  this 
domain  is  independently  and  jointly  executed  by  the  Human  Factors  Technical 
Area  in  Alexandria,  Va. ,  and  the  ARI  Field  Unit  at  Fort  Leavenworth,  Kans. 

The  present  report  describes  the  detailed  design  specifications  for  a 
man-in-the-loop  simulation  for  research,  development,  and  training.  The 
basic  concept  developed  is  one  of  a  modular  simulation  where  one  or  more 
elements  within  the  command  staff  group  may  be  exercised,  with  controllers 
supervising  play  and  feeding  in  data,  etc.,  from  unpopulated  (simulated) 
staff  elements.  Pre-established  event  threads  provide  a  means  for 
realistic  play  of  a  complex  scenario  with  a  relatively  small  controller 
team.  The  possible  role  of  computer  support  to  the  controllers  is  also 
discussed.  The  structured  framework  of  the  simulation  and  the  considera¬ 
tions  that  entered  into  its  design  are  provided  in  ARI  Technical  Report 
420.  This  effort  provides  part  of  the  methodological  and  technological 
base  required  for  development  and  evaluation  of  command  group  aids  and 
procedures. 

Research  on  staff  operations  and  procedures  is  both  conducted  in- 
house  and  augmented  contractually  with  organizations  selected  for  their 
specialized  capabilities  and  unique  facilities.  Efforts  in  this  area  are 
responsive  to  general  requirements  of  Army  Projects  2Q162722A765  and 
J2Q163743A774  and  to  special  requirements  of  the  U.S.  Army  Combined  Arms 
Combat  Development  Activity,  Fort  Leavenworth,  Kans.,  and  the  U.S.  Army 
Intelligence  Center  and  School,  Fort  Huachuca,  Ariz.  This  effort  is  also 
responsive  to  Human  Resource  Need  78-85  "War  Gaming  of  Intelligence." 

It  was  conducted  under  Contract  DAHC19-77-C-0047  by  Science  Applications, 
Inc. ,  monitored  by  both  the  Human  Factors  Technical  Area  and  the  Fort 
Leavenworth  Field  Unit  of  ARI. 


DESIGN  OF  AN  INTEGRATED  DIVISION-LEVEL  BATTLE  SIMULATION 
FOR  RESEARCH,  DEVELOPMENT,  AND  TRAINING 


BRIEF 


This  volume  provides  detailed  design  information  with  respect 
to  the  simulation.  It  should  be  read  in  the  context  of  the  structural 
framework  and  the  design  considerations  presented  in  the  companion 
volume,  DESIGN  OF  AN  INTEGRATED  DIVISION-LEVEL  BATTLE  SIMULATION  FOR 
RESEARCH,  DEVELOPMENT,  AND  TRAINING. 

Requirement: 

1.  Develop  a  top-down  design  for  an  integrated  family  of 
modular  division-level  battle  simulations  which  separately  or  jointly 
will  exercise  players  performing  critical  functions  in  command  and 
control . 


2.  Develop  detailed  design  specifications  for  the  Intelli¬ 
gence  Staff  module  of  the  integrated  battle  simulation. 

Approach: 

The  design  approach  involved  the  following  principles: 
selection  of  the  decision  variables  to  be  manipulated  by  the  division 
staff  modules  and  the  associated  inputs  and  outputs;  tying  together 
the  inputs  and  outputs  by  means  of  event  threads  both  within  and 
external  to  the  staff  modules  thereby  fixing  the  event  sequence  and 
time  of  occurrence;  and  incorporating  into  the  simulation  every  event 
thread  needed  to  support  the  input/output  relationship.  The  dynamic 
realism  needed  to  place  decision  makers  in  a  realistic  environment 
is  achieved  by  means  of  an  event  store  technique.  The  five  classes 
of  events  of  which  the  event  threads  are  composed  are  defined  and 
the  logical  flow  of  the  event  store  simulation  is  illustrated.  A 
sixth  class  of  event  needed  for  operation  in  an  ADP-assisted  mode 
is  also  defined.  The  approach  begins  at  the  heart  of  the  information 
system,  the  decisions,  and  then  develops  the  simulation  needed  to 
implement  them--the  inverse  of  the  usual  approach. 

The  design  concept  provides  for  a  man  in  the  loop  in  that 
any  one  or  any  combination  of  five  basic  staff  modules  (Cmd  Grp, 

G-2,  G-3,  G-l/G-4,  FSCE)  plus  one  enemy  module  (Cmd  Grp)  may  be 
either  occupied  by  human  players  or  simulated.  The  module  simu¬ 
lations  are  designed  as  "plug-in"  modules  any  one  or  more  of  which 
can  be  replaced  by  players.  The  simulation  also  contains  a  battle 
outcome  generator  which  simulates  all  other  events  within  the  divi¬ 
sion  and  the  enemy  force  opposing  it,  and  which  feeds  back  to  the 
players  in  slow,  real,  or  fast  time  (at  the  option  of  the  user)  the 
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results  of  their  decisions.  The  design  also  provides  for  the  inter¬ 
faces  with  higher  and  adjacent  units.  It  includes  the  following 
features: 

1.  The  modules  are  based  on  the  traditional  G-staff 
structure. 

2.  Nuclear  battle  events  are  included. 

3.  Live  modules  may  be  required  to  perform  simultaneous 
planning  and  execution;  the  results  of  such  planning 
may  be  evaluated  by  subsequent  execution  of  plans. 

4.  Other  staff  elements  not  included  in  the  basic  five 
modules  (e.g.,  engineer,  signal)  are  "hardwired" 
components  of  the  simulation. 

5.  The  basic  design  provides  for  manual  operation  by  live 
players  but  it  is  readily  expandable  to  permit  player 
operation  in  an  ADP-assisted  mode. 

Conclusions: 

The  general  top-down  design  of  the  simulation  has  been 
developed  as  has  the  more  detailed  design  of  the  Intelligence  Staff 
module.  However,  two  basic  design  problems  were  uncovered  in  the 
course  of  the  research. 

1.  A  fundamental  problem  is  inherent  in  the  modular  nature  of 
the  simulation.  If  a  populated  module  performs  below  standard 
(makes  errors,  omits  or  takes  illogical  actions)  how  can  simulated 
command  and  control  processes  reflect  the  degraded  force  effective¬ 
ness  that  results?  Although  much  simpler  to  implement,  standard 
performance  by  simulated  command  control  nodes  independent  of 
performance  of  populated  modules  would  not  meet  simulation  objectives. 

2.  In  the  interest  of  economy  of  opesation  and  player  motivation 
it  would  be  desirable  to  eliminate  or  reduce  the  requirement  for 
repetitive,  low-skill  tasks,  e.g.,  answering  radios  and  telephones, 
and  transmitting  messages,  routine  filing,  etc.,  which  have  little 
impact  on  the  quality  of  decision  making  and  are  of  little  interest 
to  the  investigator.  It  may  also  be  desirable  to  modify  or  recombine 
tasks  in  investigations  of  alternative  procedures.  This  can  be 
difficult  to  accommodate  and  still  retain  a  credible,  realistic 
decision-making  environment. 

It  is  conluded  that  both  the  above  problems  are  serious  enough  to 
warrant  additional  analysis  before  implementing  the  simulation. 
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DESIGN  NOTE  A 


LIST  OF  INDIVIDUAL  TACTICAL  INFORMATION  MESSAGES 
A. 1  EXPLANATION  OF  TABLES 

Figures  A-l  through  A-5  contain  the  list  of  individual  tac¬ 
tical  information  messages  output  by  or  input  to  the  command  or  staff 
module,  as  appropriate.  The  outputs  by  each  module  are  listed  in  the 
clear  upper  portion  of  each  table.  The  inputs  to  each  module  are 
listed  in  the  shaded  lower  portion  of  each  table. 

•  The  number  associated  with  each  tactical  information 
message  is  the  basic  reference  number  which  identifies 
each  message  regardless  of  the  class  of  the  interface 
event  it  is  used  in. 

•  "(XX)"  appears  as  the  reference  number  for  certain 
tactical  information  messages.  This  indicates  the  set 
of  input  messages  that  may  be  forwarded  by  a  particular 
module.  The  messages  that  may  be  forwarded  are  indi¬ 
cated  by  an  "R". 

•  The  "D"  after  the  reference  number  indicates  that  the 
associated  tactical  information  message  is  not  assimi¬ 
lable  by  the  computer  simulation,  and  will,  accordingly, 
only  be  utilized  by  populated  modules  as  specified  in 
Design  Notes  E,  F,  and  G. 

•  An  asterisk  after  the  reference  number  specifies  those 
messages  available  for  use  by  the  Blue  and  Red  Command 
Modules. 

•  The  specific  format  for  each  of  these  tactical  informa¬ 
tion  messages  is  contained  in  Design  Note  D. 


A-l 


Table  A-l.  Command  Group  Module. 


REF  NO  TACTICAL  INFORMATION  MESSAGE 

COMMAND  GROUP  MODULE 


01 

★ 

QUERY  BY  COMMAND  GROUP 

02 

★ 

NUCLEAR  RELEASE  REQUEST 

03  D 

MISSION  ANALYSIS 

04  D 

COMMANDER'S  GUIDANCE 

05 

★ 

COMMANDER'S  DECISION 

INITIATED  BY  COMMANDER 
RESPONSE  TO  STAFF  REQUEST 


REF  NO 


Table  A-2.  Fire  Support  Element  Module. 
TACTICAL  INFORMATION  MESSAGE 


FIRE  SUPPORT  ELEMENT  MODULE 

10 

QUERY  BY  FIRE  SUPPORT  ELEMENT 

11  D 

QUERY  ON  CORPS  FRAG  ORDER  (FIRE  SUPPORT) 

12 

FRAG  ORDER  (FIRE  SUPPORT) 

CHANGE  TO  FIRE  SUPPORT  ANNEX 

FIRE  MISSION 

13 

★ 

DIVISION  IMMEDIATE  REQUEST  FOR  FIRE  SUPPORT 

14 

DIVISION  PREPLANNED  REQUEST  FOR  FIRE  SUPPORT 

15 

* 

R 

ARTILLERY  SITUATION  REPORT 

(ALSO  INPUT) 

16 

R 

TARGET  LIST  (ARTILLERY) 

(ALSO  INPUT) 

17 

★ 

R 

FRIENDLY  UNIT  FIRE  SUPPORT  CAPABILITY 

(ALSO  INPUT) 

18 

★ 

R 

ENEMY  UNIT  FIRE  SUPPORT  CAPABILITY 

(ALSO  INPUT) 

19 

POST  STRIKE  ANALYSIS 

20  D 

FIRE  SUPPORT  ANNEX 

21 

REQUEST  BY  FIRE  SUPPORT  ELEMENT 

FOR  RELEASE 

FOR  CONCURRENCE 

22 

RESPONSE  TO  REQUEST 

RELEASE/HOLD 

CONCURRENCE/NON-CONCURRENCE 

(XX) 

— — t  — 

(Retransmittal  of  a  Received  Message) 

_ — r- — r - - — ^ 

AlR  SUPPORT 


REQUEST  FORxf I^KSUPPORr 

\  \\V 

£LEMENTSUPP0RT  STATUS 
D£F£.NS|  ARTILLERY  \\\\ 
ATR, SORTIES  \  '  \ 

B  IOLGG  LCAL ,  CAEMKAL  \ 
x  OrM  (FI  RE '  SUPPORT )' . 
SP£C  ik/EST4 MATE/AWNEX 

BIOLOGICAL  jv  SHEMTCAL 


Table  A-3.  Intelligence  Staff  Module. 


REF  NO _ TACTICAL  INFORMATION  MESSAGE 


INTELLIGENCE  STAFF  MODULE 

30 

QUERY  BY  INTELLIGENCE  STAFF 

31  D 

QUERY  ON  CORPS  FRAG  ORDER  (INTELLIGENCE) 

32 

FRAG  ORDER  (INTELLIGENCE) 

33  D 

DIVISION  INTELLIGENCE  SUMMARY 

34  * 

NUCLEAR,  BIOLOGICAL,  CHEMICAL  REPORT 

(ALSO  INPUT) 

35  *  R 

WEATHER  FORECAST 

(ALSO  INPUT) 

36 

INTELLIGENCE  PARAGRAPH  OF  DIVISION  SITUATION  REPORT 

37  D 

INTELLIGENCE  ESTIMATE 

38  D 

INTELLIGENCE  ANNEX 

39 

REQUEST  BY  INTELLIGENCE  STAFF 

FOR  RELEASE 

FOR  CONCURRENCE 

40 

RESPONSE  TO  REQUEST 

RELEASE/HOLD 

CONCURRENCE/NON-CONCURRENCE 

(XX) 

(Retransmittal  of  a  Received  Message) 

Table  A-4.  Operations  Staff  Module. 


REF  NO 


TACTICAL  INFORMATION  MESSAGE 


OPERATIONS  STAFF  MODULE 


h9 

70 

?t  0 

n  o 


QUERY  BY  OPERATIONS  STAFF 

QUERY  ON  CORPS  FRAG  ORDER  (OPERATIONS) 

FRAG  ORDER  (OPERATIONS) 

OPERATIONS 
ELECTRONIC  WARFARE 
DIVISION  SITUATION  REPORT 
NUCLEAR  WARNING  ORDER 
AIR  DEFENSE  WARNING 

*  REQUtST  FOR  RESERVES 
OPERATIONS  PLAN 
OPERATIONS  ESTIMATE 

*  R  INITIAL  ENEMY  CONTACT 

*  R  UNIT  PL"  SS  REPORT 

If  T 

i  FACT 

WITH  FRIENDLY  UNIT 

*  »  -l  v  Mi  Electronic  order  of  battle 

KlOJEST  BY  OPERATIONS  STAFF 
FOR  RELEASE 
FOR  CONCURRENCE 
RESPONSE  TO  REQUEST 
RELEASE/HOLD 

CONCURPENCE/NON-CONCURRENCE 
(.Retransmittal  of  a  Received  Messaqe) 
BhT^AUE/^A'TT  Ac  tOfF  TbAT  I ONREP0RT  x\ 
AIR  DEFENSE  ALERT  \\\  \ 

*  R  ORGANIC  AVIATION  SORTIE  $TAH)$  \\X 

QUERY  ON  FRAG  ORDER  ('8PERATTQNs>  \Xx 
OPERATIONS  x  \V  \\ 

ELECTRONIC  WARFARE  • " \'  x  X 
QUERY  ON  NO  CLEAR  WARNING  ORBEW  \  V 

Query  on  air  defense  warning'  \\V 

CORPS  FRAG  ORDER  [DPERMIoRS)x  ,''  '  \'' 
OPERATIONS  SPECIAL  ESTIMAIE/MNL*  n  X 
AVIAJTOA  '  \\\\ s 

.  \  .  Communications  \W  s\\\\ '• 
ENGINEERS  V  ''  xX  \\\ 


(ALSO  INPUT) 
(ALSO  INPUT) 


(ALSO  INPUT) 
(ALSO  INPUT) 


\V  \ 


Table  A-5.  Coinoat  Service  Support  Staff  Module. 


REF  NO _ TACTICAL  INFORMATION  MESSAGE 

COMBAT  SERVICE  SUPPORT  STAFF  MODULE 


80  QUERY  BY  COMBAT  SERVICE  SUPPORT  ELEMENT 

81  D  QUERY  ON  CORPS  FRAG  ORDER  (COMBAT  SERVICE  SUPPORT) 

82  FRAG  ORDER  (COMBAT  SERVICE  SUPPORT) 

CHANGE  TO  COMBAT  SERVICE  SUPPORT  ANNEX 
MEDICAL  EVACUATION 
RESUPPLY 
TROOP  LIFT 

83  D  DIVISION  PERSONNEL  DAILY  SUMMARY 

84  D  PERIODIC  LOGISTIC  REPORT 

85  D  *  PERSONNEL  REQUISITION 

86  D  R  IMMEDIATE  REQUEST  FOR  LOGISTICAL  SUPPORT  (ALSO  INPUT) 

87  D  COMBAT  SERVICE  SUPPORT  ESTIMATE 

88  D  COMBAT  SERVICE  SUPPORT  ANNEX 

89  REQUEST  BY  COMBAT  SERVICE  SUPPORT  STAFF 

FOR  RELEASE 
FOR  CONCURRENCE 

90  RESPONSE  TO  REQUEST 


RELEASE/HOLD 

CONCURRENCE/NON-CONCURRENCE 
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DESIGN  NOTE  B 

MODULE  OUTPUTS  AND  THEIR  MODULAR  ADDRESSES 


B.l  EXPLANATION  OF  TABLES 

Table  B-l  lists  the  outputs  of  the  Conwand  Group,  each  principal 
staff  module,  corps  and  adjacent  divisions,  special  staff  and  organic 
units  subordinate  to  the  division  headquarters  and  indicates  where  the 
tactical  information  messages  may  be  addressed.  In  the  event  a  partic¬ 
ular  command  or  staff  module  is  simulated,  these  addresses  are  "hard¬ 
wired".  For  a  populated  module  the  addressee  will  be  as  determined 
by  the  players.  The  outputs  from  corps  adjacent  divisions,  and  for 
the  tactical  documents  required  by  populated  modules  from  simulated 
modules  or  the  special  staff  will  be  distributed  by  the  controller 
in  accordance  with  the  "play"  of  the  event-store  simulation. 


B-l 


Table  B-l .  Module  Outputs  and  their  Modular  Addresses. 


TACTICAL  INFORMATION  MESSAGE 

COMMAND  GROUP 
01  QUERY 
02  NUC  REL  REq 
030  MSN  ANAL 
040  CMDR'S  GUIO 
05  CMDR'S  DEC 
XX  RETRANSMIT 


1  CORPS 


ADJ 

DIV 


iCMDl  PSE I  G2  I  G3 


10 

QUERY 

gpfpi 

X 

X 

X 

Hx 

110 

QUERY 

X 

12 

FRAG  ORDER  (FS) 

X 

X 

X 

X 

X 

X 

X 

13 

DIR  FIRE  SPT 

X 

X 

lilSfS 

X 

14 

OPR  FIRE  SPT 

X 

IppHi 

X 

15 

ARTY  SITREP 

X 

X 

16 

TGT  LIST  (ARTY) 

WT':  3 

X 

X 

17 

FU  FIRE  SPT  CAP 

X 

X 

18 

EU  FIRE  SPT  CAP 

■?$?:  ■'  Y'; 

X 

i  X 

i 

19 

POST  STRIKE  ANAL 

X 

* 

X 

i  * 

20D 

FIRE  SPT  ANNEX 

i.v  b  f. 

1  X 

21 

REQUEST 

X 

X 

i  X 

X 

22 

RESPONSE 

< 

7  -  <0 

X 

X 

X 

XX 

RETRANSMIT 

X 

C'H" 

X 

1  V 

t  x 

X 

1 

INTELLIGENCE  STAFF 

b«''* 

v'-:\ 

%;■  V! 

inis 

30 

QUERY 

X  i 

p'  ’  i 

X 

X 

310 

QUERY 

X 

32 

FRAG  ORDER ( I ) 

X 

X 

X 

X 

pmS 

X 

X 

X 

330 

OIV  INTSUM 

X 

X 

X 

gM 

X 

X 

34 

NBC  REPORT 

X 

X 

X 

X 

11  J| 

X 

X 

35 

WX  FORECAST 

X 

X 

llpl  '1 

X 

X 

36 

INTELL  INPUT  TO  OIV  SITREP 

A 

X 

370 

INTELL  EST 

X 

X 

X 

X 

380 

INTELL  ANNEX 

X 

39 

REQUEST 

X 

X 

gifli 

X 

X 

40 

RESPONSE 

X 

p';,1 

X 

X 

XX 

RETRANSMIT 

L__— 

X  1 

1 

X 

§7:7 

7 

X 

X 

OPERATIONS  STAFF 

r~i 

v 

L:  -■ 

7  •  -y 

50 

QUERY 

X 

X 

1  i 

X 

;  r 

510 

QUERY 

X 

f .  ' 

52 

FRAG  ORDER  (OPS) 

X 

X 

X 

X 

X 

X 

X 

530 

DIV  SITREP 

X 

X 

; 

X 

54 

NUC  WARNING  ORDER 

1  X 

1  X 

X 

X 

•  ••  3$ 

X 

X 

55 

AD  WARNING 

X 

1  X 

1  X 

X 

X 

X 

X 

56 

REQ  C0R  RESERVES 

1  X 

1 

57D 

OP  PLAN 

X 

X 

X 

X 

•  ?%$ 

X 

580 

OP  EST 

!  x 

X 

X 

X 

59 

INITIAL  EN  COST 

X 

X 

60 

UNIT  PROG  RPT 

' 

61 

LOSS  CONT  W/FU 

X 

X 

62 

EOOB 

1 

X 

:< 

63 

REQUEST 

i 

< 

X 

( 

' 

X 

64 

RESPONSE 

! 

7 

XX 

RETRANSMIT 

1  X  i 

X 

1 

1 

X 

+  vi 

X 

G1/G4 


DIV 
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Table  B-l.  Module  Outputs  and  their  Modular  Addresses.  (Continued) 


TACTICAL  INFORMATION  MESSAGE 


G1/G4  DIV 


COMBAT  SERVICE  SPT  STAFF 
80  QUERY 
810  QUERY 

82  FRAG  ORDER  (CSS) 
830  OIV  POS 
840  PER  LOG  RPT 
85D  PERS  REQ 
860  IR  LOG  SPT 
870  CSS  EST 
880  CSS  ANNEX 

89  REQUEST 

90  RESPONSE 
XX  RETRANSMIT 


0  GENERAL  SIT 
0  SPECIAL  SIT 
290  FRAG  ORDER  (FS) 
34  NBC  REPORT 
44  CBT  INTELL  RPT 
49 D  FRAG  ORDER  (I) 
710  FRAG  ORDER  (OPS) 
950  FRAG  ORDER  (CSS) 


AOJACENT  DIVISION 
23  IR  FIRE  SPT 


SPECIAL  STAFF 


FSE  SPT  STATUS 
FS  EST/ANNEX 
AVN  SORTIE  STATUS 
OPS  EST/ANNEX 
DISCOM  SITREP 
CMQ  EST/ANNEX 


DIVISION 

15  ARTY  SITREP 

16  TGT  LIST  (ARTY) 

17  FU  FIRE  SPT  CAP 

18  EU  FIRE  SPT  CAP 

23  IR  FIRE  SPT 

24  PR  FIRE  SPT 

25  TGT  ( I ) 

27  QUERY  I FS) 

34  NBC  REPORT 

35  WX  FORECAST 

41  BOE  INTSUM 

42  SHELL  REPORT 

43  SPOT  REPORT 

44  CBT  INTELL  RPT 

45  POST  STRIKE  DAM  RPT 

46  EST  OF  EN  STRENGTH 

47  TGT  LIST  (I) 

48  QUERY  (I) 

59  INITIAL  EN  CONT 

60  UNIT  PROG  RP' 

61  LOSS  CCNT  W/FU 

62  ECOB 

65  BOE/ BN  SITF.EP 

66  AO  ALERT 

68  QUERY  (OPS) 

69  QUERY  (NWC) 

70  QUERY  (AOW) 

36  IR  LOG  SPT 

91  3DE/BN  POS 

92  CAPE  REPORT 

93  PR  LOS  SPT 

94  QUERY  (CSS) 
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DESIGN  NOTE  C 


INPUT/OUTPUT  MATRICES 
C.l  EXPLANATION  OF  TABLES 

Tables  C-l  through  C-5  define  the  relationship  between  inputs, 
from  all  sources,  to  each  module  and  the  associated  outputs.  The  in¬ 
put  messages  and  their  sources  are  listed  in  the  left  hand  column  of 
each  table  and  outputs  are  presented  along  the  top.  The  unique  refer¬ 
ence  number  defined  in  Design  Note  A  is  also  restated  for  each  input/ 
output  message. 

An  "X"  at  the  intersection  of  a  row  (input)  and  a  column  (out¬ 
put)  indicates  that  information  contained  within  the  input  message 
may  be  used  in  the  production  of  the  output  message.  Accordingly,  it 
is  recognized  that  these  relationships  between  the  input/output  mes¬ 
sages  define  a  portion  of  the  Class  1  events  for  simulated  staff 
modules.  Appropriate  algorithms  will  be  defined  for  producing  out¬ 
puts  from  the  inputs.  Obviously,  players  within  populated  modules 
will  determine  their  own  internal  procedures  required  to  produce  out¬ 
puts  from  the  given  inputs. 

The  RETRANSMIT  output  within  each  matrix  indicates  those  inputs 
which  are  subject  to  retransmission  by  the  receiving  module.  These 
messages  correspond  to  those  presented  in  subsection  4.1.2. 
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Table  C-l.  Input/Output  Matrix  for  Command  Group  Module 


Table  C-2.  Input/Output  Matrix  for  Fire  Support  Element 
Module . 
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Table  C-3.  Input/Output  Matrix  for  Intelligence  Staff  Module 


Table  C-4.  Input/Output  Matrix  for  Operations  Staff  Module. 
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DESIGN  NOTE  D 

FORMATS  OF  INDIVIDUAL  TACTICAL  INFORMATION  MESSAGES 

This  design  note  contains  the  formats  for  all  the  tactical 
information  messages  contained  in  Design  Note  A.  The  formats  are 
listed  in  order  by  the  embedded  reference  number  given  in  that  design 
note.  In  some  instances  explanatory  information  about  the  use  of  the 
format  is  given.  The  standard  heading  for  all  message  formats  is  given 
on  page  0-2  and  only  the  body  of  the  formats  is  given  on  the  following 
pages. 


STANDARD  HEADING  FOR  ALL  MESSAGES* 


PRECEDENCE**/DTG 

SECURITY  CLASSIFICATION 

FROM 

TO 

INFO 

TYPE  REPORT 


*This  is  the  standard  heading  for  all  exchange  messages. 

**Precedence  establishes  routing  and  handling  procedures  with  simulated 
modules.  Allowable  procedures  are: 

F  -  FLASH 

I  -  IMMEDIATE 

P  -  PRIORITY 

R  -  ROUTINE 


XX  RETRANSMIT  MESSAGE* 


1.  Additional  Addresses 

(Inserted  at  the  beginning  of  the  original  message) 


*Any  module  may  retransmit  any  received  message  deemed  appropriate  to  any 
other  module  not  included  on  the  initial  distribution.  Criteria  for  re¬ 
transmission  within  a  simulated  module  will  be  based  upon  time  sensitivity 
or  importance  of  the  information. 


01  QUERY  BY  COMMAND  GROUP* 

1.  Message  Required  _ . 

2.  DTG  of  Need 

3.  Required  of  all  units  (Yes  _ No  _ ;  if  no  complete  4). 

4.  Specific  battalions 

a. 

b. 

c. 

d. 

e. 


*The  following  list  indicates  the  allowable  queries  for  the  Command 
Group.  They  may  be  either  Class  2  or  Class  3  queries.  Responses  to 
Class  3  from  the  BOG  will  contain  more  current  information  but  will  be 
limited  in  the  number  of  units  presented.  Responses  to  Class  2  events 
for  the  cognizant  staff  will  contain  information  concerning  more  units 
but  the  information  will  not  be  as  current. 

15.  Arty  SITREP 

16.  Tgt  List  (Arty) 

17.  FU  FS  CAP 

18.  EU  FS  CAP 

24.  PR  for  FS 

26.  FSE  Spt  Status 

41.  BDE  INTSUM 

46.  Est  of  En  Strength/Disp 

47.  Tgt  List  (I) 

60.  Unit  Prog  Rpt 

62.  EOOB 

65.  Bde/Bn  SITREP 

67.  AVN  Sortie  Status 

91 .  Bde/Bn  PDS 

92.  CAPE  Rpt 

93.  PR  for  Loq  Spt 
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02  NUCLEAR  RELEASE  REQUEST 

1.  Request  for  Use  of  Subpackage _£ _ 

2.  Purpose 

3.  Timespan  (in  minutes) 

4.  Area  of  Subpackage 

5.  Employment  Constraints 

6.  Weapons 

7.  Number  and  Size  of  Weapons 

8.  Justification 


*Nuclear  subpackages  must  be  planned  in  advance.  These  subpackages  must 
be  in  the  form  of  a  Corps  Frag  Order  (FSE)  and  must  be  assimiliable 
by  the  simulation. 


03D  MISSION  ANALYSIS* 

1.  Purpose 

2.  Time  to  be  Accomplished 

3.  Personnel  Considerations 

4.  Essential  Elements  of  Information 

5.  Courses  of  Action 

6.  Logistic  Considerations 

7.  Fire  Support  Considerations 


*This  format  is  only  used  by  players  within  a  populated  command  module 
Upon  receipt  of  a  new  mission  from  corps,  it  is  used  as  a  guide  to  pre 
pare  an  analysis  of  the  new  mission.  This  analysis  will  be  used  only 
by  populated  staff  modules  as  a  basis  for  preparing  staff  estimates. 
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040  COMMANDER’S  GUIDANCE* 


1.  Summary  of  Mission  Analysis 

2.  General  Plan  for  NBC  Warfare 

3.  Courses  of  Action  to  be  Developed 

4.  Essential  Elements  of  Information 

5.  Other  Factors 

a.  Logistic  Considerations 

b.  Personnel 

c.  Reserves 

d.  Fire  Support 


★This  format  is  only  used  by  players  within  a  populated  command  module. 
It  is  to  be  used  in  conjunction  with  the  mission  analysis  by  populated 
staff  modules  as  a  basis  for  completing  staff  estimates. 
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05  COMMANDER'S  DECISION* 


A 

1 .  Proposed  Release 

2.  Concur  _  Nonconcur 

(Added  to  a  completed  frag 

order) 


B 

1.  Execute 

(Added  to  a  completed  frag 
order) 


*Decision  A  is  the  cormand  module  response  (whether  populated  or  simulated) 
to  the  request  for  release  of  a  frag  order  from  any  of  the  staff  modules. 
Decision  B  is  for  use  by  a  populated  command  module  when  initiating  a  frag 
order. 
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TitKESmi 


1.  Message  required  _ . 

2.  DTG  of  Need 

3.  Required  of  all  units  (Yes 

4.  Specific  Battalions 

a. 

b. 


c. 

d. 


e. 


,  No  _ ;  if  no  complete  4) 


*The  following  list  indicates  the  allowable  queries  for  the  FSE  module. 


Class  3 

Class  2 

15. 

Arty  SITREP 

41 . 

BDE  INTSUM 

16. 

Tgt  List  (Arty) 

46. 

Est  of  En  Strength/Disp 

17. 

FU  FS  CAP 

47. 

Tgt  List  ( I ) 

18. 

EU  FS  CAP 

60. 

Unit  Prog  Rpt 

24. 

PR  for  FS 

62. 

EOOB 

26. 

FSE  Spt  Status 

65. 

Bde/Bn  SITREP 

67. 

AVN  Sortie  Status 

91. 

Bde/Bn  PDS 

92. 

CAPE  Rpt 

93. 

PR  for  LOG  SP 

0-9 


This  is  a  free  text  query  by  a  populated  FSE  of  CORPS  (controller). 


12  FRAG  ORDER  (FIRE  SUPPORT) 

A.  (Change  to  FS  Plan/Annex) 

1 .  Frag  Order  Number 

2.  Enemy  Situation 

3.  Friendly  Situation 

4.  Any  Change  to  Task  Organization 

5.  Orders  to  Subordinate  Units 

6.  Fire  Support  Considerations 

7.  Coordinating  Instructions 

B.  (Fire  Mission) 

1.  Fire  Mission  Number 

2.  Target  Location 

3.  Target  Description 

4.  Quantity 

5.  Acti vi ty /Movement 

6.  Vulnerabil ity 

7.  DTG  (of  Observation) 

8.  DTG  (TOT) 

9.  Target  Number 

10.  Fire  Control 


"A"  would  be  used  to  attach/detach  elements;  change  support  role, 
priority  of  fire,  coordination  measures,  etc. 

"B"  would  be  used  to  order  a  fire  mission. 
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13,  14,  23,  24  REQUEST  FOR  ADDITIONAL  FIRE  SUPPORT* 


ARTY/NGF 

CAS 

1. 

Target  Description 

1. 

Target  Description 

2. 

Quantity 

2. 

Quanti ty 

3. 

Target  Priority 

3. 

Target  Priority 

4. 

Vulnerability 

4. 

Vulnerability 

5. 

Acti vi ty /Movement 

5. 

Activity/Movement 

6. 

Location/Elevation 

6. 

Location/Elevation 

7. 

Atti tude 

7. 

Attitude 

8. 

Length/Width 

8. 

Length/Width 

9. 

DTG 

9. 

DTG  (TOT) 

10. 

Method  of  Engagement 

10. 

Recommended  Aircraft  & 

11. 

Method  of  Fire  &  Control 

Ordnance 

11. 

Tactical  Situation 

12. 

Nearest  Friendlies 

13. 

Final  Control 

*Thi$  requests  may  be  either  preplanned  or  immediate.  Preplanned  requests 
are  forwarded  periodically  or  after  a  query  by  the  FSE/Command  Group 
(#24).  Immediate  requests  are  forwarded  after  need  arises.  DTG  will 
be  replaced  by  ASAP  (#23).  The  division  aggregates  these  respective 
request  and  forwards  to  corps  or  adjacent  headquarters  (13  and  14). 
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15  ARTY  SITREP* 

1.  Period  Covered  (FM  DTG  to  DTG) 

2.  Location  of  Unit  Command  Post  and  Closina  Time 

a.  Location  of  Battalion  Centers 

b.  Direction  of  Center  of  Zone  of  Fire 

c.  Proposed  New  Location  and  Effective  Time 

3.  Nc  Fire  Line 

4.  Number  of  Missions  Fired 

5.  Enemy  Casualties 

6.  Materiel  Destroyed 

a.  Type/Number 

7.  Personnel  Losses 

a.  KIA 

b.  WIA 

8.  Ammunition  Status 

Type  Rounds  on  Hand  Rounds  Expended  During  Period 

a.  HE 

b.  Smoke 

c.  Other 

d.  Total 

9.  Shortages  of  Personnel/Equipment/Fuel/Ammunition  which  Effect 
Unit/flission 

10.  Combat  Effectiveness 

11.  Plans  for  Support  of  Future  Operations/Incidents  of  Immediate  Value 


*This  SITREP  is  sent  to  FSE  by  the  DIV  ARTY.  DIV  ARTY  must  aggregate 
the  required  information  from  task  organized  artillery  units. 
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1.  Target  Number 

2.  Description 

3.  Location 

4.  Remarks 

5.  Results 


★Same  information  Ts  required  for  each  target. 


17  FRIENDLY  FIRE  UNIT  CAPABILITY* 

1.  Unit 

2.  Callsign  (Telephone/Radio) 

3.  Present  Location 

4.  Time  Reported  Displaced 

5.  Proposed  Location 

6.  Time  Closed 

7.  Center  of  Sector 

8.  Mission  (Direct  Support,  Etc.) 

9.  Active  (Tubes/Launcher) 

10.  Readiness 

11.  Remarks 


*This  is  a  table  which  is  repeated  for  each  unit.  In  manual  mode  lowest 
reported  unit  will  be  a  battalion  -  for  a  staff  with  ADP  assistance  the 
lowest  reported  unit  will  be  a  battery. 
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18  ENEMY  UNIT  FIRE  SUPPORT  CAPABILITY* 

1.  Known  and  Suspected  Artillery  BNS 

a.  Type 

b.  Quantity 

c.  Self  Propelled/Towed 

d.  Range 

e.  Location  (Estimate) 

f.  Nuclear  Capable? 

2.  Relative  ARTY  Strength  Ratio  (Enemy/Friendly) 

3.  Estimate  of  Enemy  Ammunition  Resupply  Rate 

4.  Remarks 


♦Estimate  of  enemy  ammunition  resupply  rate  has  to  be  included  in  initial 
data  -  primary  source  for  remaining  info  is  from  counter  battery/mortar 
radars  via  DIV  ARTY. 
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19  POST  STRIKE  ANALYSIS* 


1.  Target  Description 

2.  Location  of  Ground  Zero 

3.  Subpackage: _  /TOT: 

4.  Estimate  of  Enemy  Casualties 

a.  Personnel 

b.  Equipment 

5.  Estimate  of  Civilian  Casualties 

6.  Estimate  of  Enemy's  Capability  to  Continue  the  Fight 


*Used  by  FSE  module  to  ascertain  affects  of  nuclear  strike  by  friendly 
forces.  Post  Strike  Damage  reports  from  the  G2  are  required  to  conduct 
the  analysis. 
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20D  FIRE  SUPPORT  ANNEX* 


1.  General 


a.  Concept  of  Operation 

(1 )  Maneuver 

(2)  Fires 

2.  Fire  Support 

a.  FA 

(1)  General 

(2)  Organization  for  Combat 

(3)  Special  Instructions 

b.  CAS 

(1 )  General 

(2)  Special  Instructions 

c.  NGF 

(1 )  General 

(2)  Allocation  of  NGF  Support 

(3)  Special  Instructions 

d.  Nuclear 

(1)  General 

(2)  PNL 

e.  Chemical 

(1 )  General 

(2)  PCL 

3.  Fire  Support  Coordinating  Instructions 


*This  format  is  only  used  by  players  within  a  populated  FSE  module.  The 
format  is  self-explanatory  and  is  to  be  used  as  a  guideline  by  the  players 
for  producing  a  Fire  Support  Annex  as  required. 


A 

1 .  Proposed  Release 

2.  Concur  _  Nonconcur  _ 

(Added  to  a  completed 

Frag  Order  (FS)) 


B 

1.  Please  Execute 

2.  Concur  _ 

Nonconcur  _ 

(Added  to  a  com¬ 
pleted  Frag  Order) 


C 

1.  Please  Review 

2.  Concur  _  Nonconcur  __ 

(Added  to  a  completed 

Frag  Order  (FS)) 


*Request  A  is  forwarded  to  the  command  module  for  a  decision  when  the 
content  of  the  Frag  Order  (FS)  broaches  thresholds  as  established  by  the 
commanders  guidance  or  delegated  authority. 

Request  B  is  for  use  by  a  populated  FSE  module  when  initiating  a  frag 
order  not  within  its  purview.  The  message  is  sent  to  the  staff  module 
having  staff  cognizance. 

Request  C  is  for  use  by  the  FSE  module  when  a  proposed  frag  order  requires 
a  "chop"  from  another  staff  module. 


22  RESPONSE  TO  REQUEST 


The  response  to  request  B  consists  of  the  information  copy  of 
the  Frag  Order  (FSE)  if  accepted  by  the  FSE  or  the  return  of  the  request 
if  not. 

The  response  to  request  C  consists  of  the  request  including  the 
completed  Frag  Order  in  question  with  concurrence  or  non-concurrence 
filled  in  as  appropriate  (see  21). 

The  response  to  a  query  is  the  appropriate  Class  4  event. 


25  TARGET  (INTELLIGENCE) 

1.  DESCRIPTION 

2.  LOCATION 

3.  EVALUATION/SOURCE 

4.  REMARKS 
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26  FIRE  SUPPORT  ELEMENT  SUPPORT  STATUS* 

A.  Air  Defense  Artillery  C.  Nuclear,  Biological,  Chemical 


1 . 

Type  Unit 

1 . 

Means 

2. 

Location 

2 

Yield 

3. 

Readiness  Condition 

3. 

TGT  Number 

4. 

Alert  Status 

4. 

Description 

5. 

Quantity  of  "GO"  Missiles 

5. 

Aim  Point 

6. 

Range 

B.  Tactical  Air  Sorties 

1.  Preplanned 

a.  Number  and  Type  Aircraft 

b.  Target 

c.  Ordnance 

d.  Expected  Time  of  Arrival 

e.  Supported  Unit 

2.  On  Call 

a.  Number  and  Type  Aircraft 

b.  Target 

c.  Ordnance 

d.  Alert  Status 

e.  Supported  Unit 

3.  Immediate 

a.  Number  and  Type  Aircraft 

b.  Ordnance 

c.  Alert  Status 


*These  formats  used  to  keep  the  FSE  module  abreast  of  the  ADA,  TAS,  and 
NBC  situation.  Each  ADA  unit  will  be  represented  in  A.  B1 ,  2,  or  3 
will  be  available  for  each  TAS  mission.  C  is  used  to  define  nuclear 
subpackage.  Multiple  targets  are  contained  within  each  subpackage. 
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27  QUERY  ON  FRAG  ORDER  (FS) 

The  format  for  this  message  will  be  the  received  message  with 
notations  indicating  technical  inaccuracies. 
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28D  FIRE  SUPPORT  SPECIAL  ESTIMATE/ANNEX* 


A.  Air  Defense  Artillery 

1.  Situation 

a.  Enemy  Forces  (TAS  capability) 

b.  Friendly  Forces  (air  defense  unit) 

c.  Assumptions 

2.  Mission 

3.  Execution 

a.  Unit  Tasks 

b.  Control  of  Fire 

c.  Alert  Status 

d.  Electronic  Warfare 

e.  Priorities  for  Protection 

f.  Coordinating  Instructions 

4.  Service  Support 

a.  General 

b.  Materiel  Services 

5.  Command  and  Signal 

B.  Tactical  Ai r  Sorties 

1.  Situation 

a.  Enemy  Forces  (Air  Defense,  etc.) 

b.  Friendly  Forces  (Aviation  Units) 

c.  Assumptions 

2.  Mission 

3.  Execution 

a.  Close  Air  Support 

(1)  Preplanned 

(2)  On  Call 

(3)  Immediate 

♦These  formats  are  input  to  a  populated  FSE  module  for  use  in  preparing 
a  Fire  Support  Annex.  These  documents  must  be  prepared  in  advance  of 
the  play  of  the  game. 
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28D  FIRE  SUPPORT  SPECIAL  ESTIMATE/ANNEX  (Continued) 

B.  Tactical  Air  Sorties  (cont.) 

3.  Execution 

b.  Air  Reconnaissance 

c.  Electronic  Warfare 

d.  Air  Lift 

e.  Aircraft  Status 

(1)  Type 

(2)  Number  Available 

(3)  Maintenance  Status 

(4)  Alert  Status 

f.  Coordinating  Instructions 

(1)  Air  Request  Procedure 

(2)  Air  Support  Radar  Teams 

4.  Service  Support 

a.  General 

b.  Materiel  Services 

(1)  POL 

(2)  Air  Bases 

5.  Command  and  Signal 

C.  Nuclear,  Biological,  Chemical 

1.  Situation 

a.  Enemy  Forces 

b.  Friendly  Forces 

c.  Assumptions 

(1)  Defense  Severely  Tested 

(2)  Corps  Requests  Nuclear  Package 

(3)  Chemical  Authorization 

2.  Mission 

a.  Provide  Nuclear  Fire  Support 

b.  Provide  Chemical  Fire  Support  of  Division 


28D  FIRE  SUPPORT  SPECIAL  ESTIMATE/ ANNEX  (Continued) 
C.  Nuclear,  Biological,  Chemical  (cont.) 

3.  Execution 

a.  Nuclear 

(1)  Concept  (subpackages  A,  6,  etc.) 

(2)  Constraints 

(3)  Nuclear  Warning  Order 

(4)  Nuclear  Aimpoints 

b.  Chemical 

(1)  Concept  of  Employment 

(2)  Targets 

c.  Coordinating  Instructions 

( 1 )  Weather 

(2)  Authorization  Procedures 

4.  Service  Support 

a.  General 

b.  Materiel  Services 

5.  Command  and  Signal 


29 D  CORPS  FRAG  ORDER  (FIRE  SUPPORT)* 

A.  (Change  to  FS  Plan/Annex) 

1.  Frag  Order  Number 

2.  Enemy  Situation 

3.  Friendly  Situation 

4.  Any  Change  to  Task  Organization 

5.  Orders  to  Subordinate  Units 

6.  Fire  Support  Considerations 

7.  Coordinating  Instructions 

B.  (Fire  Mission) 

1.  Fire  Mission  Number 

2.  Target  Location 

3.  Target  Description 

4.  Quantity 

5.  Activity/Movement 

6.  Vulnerability 

7.  DTG  (of  Observation) 

8.  DTG  (TOT) 

9.  Target  Number 

10.  Fire  Control 


*These  formats  are  used  by  the  controller  to  interject  investi aator 
objectives  into  the  play  of  the  game.  "A"  would  be  used  to  attach/ 
detach  elements;  change  support  role,  priority  of  fires,  coordination 
measures,  etc.  "B"  would  be  used  to  order  a  fire  mission. 


30  QUERY  BY  INTELLIGENCE  STAFF* 


1.  Message  Required  _ . 

2.  DTG  of  Need 

3.  Required  of  all  units  (Yes  _ ,  No  _ ;  if  no  complete  4) 

4.  Specific  Battalions 

a. 

b. 


c. 

d. 

e. 


*The  following  lists  indicate  the  allowable  queries  for  the  G2  module. 


Class  3  Class  2 


41. 

BDE  INTSUM 

15. 

Arty  SITREP 

46. 

EST  of  EN  Strength/Disp 

16. 

Tgt  List  (Arty) 

47. 

TGT  List  (I) 

17. 

FU  FS  CAP 

18. 

EU  FS  CAP 

24. 

PR  for  FS 

26. 

FSE  SPT  Status 

60. 

Unit  Prog  Rpt 

62. 

EOOB 

65. 

BDE/'BN  SITREP 

67. 

AVN  SortiesStatus 

91. 

BDE/BN  PDS 

92. 

CAPE  Rpt 

93. 

PR  for  Log  SPT 

D-28 
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310  QUERY  ON  CORPS  FRAG  ORDER  (INTELLIGENCE) 

This  is  a  free  text  query  by  a  populated  G2  of  Corps  (controll 


I 
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32  FRAG  ORDER  (INTELLIGENCE) 

1.  Mission  Number 

2.  DTG  of  Need 

3.  Subject/Description 

4.  Location 

5.  Task 

6.  Change  in  EE  I 


33D  DIVISION  INTSUM* 


1.  Summary  of  Enemy  Activity 

a.  Ground 

b.  Trace  of  Forward  Elements 

c.  Potential  Targets  for  Nuclear  Attack 

d.  Nuclear  Activity 

e.  Chemical/3iological  Activity 

f .  Air  Acti  vi  ty 

g.  Other 

2.  Enemy  Personnel/Equipment  Losses 

a.  KIA 

b.  POW 

c.  Equipment  Destroyed/Captured 

3.  Counter  Intelligence 

4.  Obstacles/Barriers 

5.  Identifications 

a.  Units 

b.  Personalities 

6.  Enemy  Movements 

7.  Estimated  Number  and  Type  Vehicles 

8.  Weather/Terrain 

9.  Capabilities/Vulnerabilities 

10.  Conclusions 


*This  report  is  an  aggregation  of  subordinate  units  and  ASAC  reports. 
It  is  forwarded  to  Corps  by  populated  G2  modules. 


34  NBC  REPORT 


tn 


A.  STRIKE  SERIAL  NUMBER 

B.  POSITION  OF  OBSERVER 

C.  AZIMUTH  OF  ATTACK 

D.  DTG  OF  ATTACK 

E.  ILLUMINATION  TIME  (SEC) 

/ATTACK  ENDED 

F.  LOCATION  OF  ATTACK 

G.  MEANS  OF  DELIVERY 

H.  TYPE  OF  BURST/AGENT 

I.  NUMBER  OF  ROUNDS 

J.  FLASH-TO-BANG  (SEC)  TO  BURST 

K.  CRATER  PRESENT  OR  ABSENT 

L.  NUCLEAR  CLOUD  WIDTH  (@  H+5  MIN) 


1 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


BC 


M.  STABILIZE  CLOUD  TOP  OR  BOTTOM 
ANGLE  0  H+10  MIN 

N.  ESTIMATED  YIELD 

O.  REFERENCE  DTG  (NOT  H+l ) 

P.  AREA  OF  EXPECTED  CONTAMINATION 

Q.  LOCATION  OF  READING 

R.  DOSE  RATE 

S.  DTG  OF  READING 

T.  DTG  OF  H+l 

U.  1000  RAD/HR 

V.  300  RAD/HR 

W.  100  RAD/HR 

X.  30  RAD/HR 

Y.  L&R  RADIAL  LINES 

Z.  EFFECTIVE  WIND  SPEED 


X 


35  WEATHER  FORECAST 


1.  Period  (FM  _ ;  TO  _ ) 

2.  Synoptic  Condition 

3.  Sky  Condition 

4.  Visibility 

5.  Precipitation 

6.  Weather  Phenomena 

7.  Temperature 

8.  Humidity 

9.  Winds  (Speed,  Direction) 

10.  Pressure  and  Density 

11.  Surface  Conditions 

12.  Turbulence  and  Icing  Aloft 

13.  Light  Data 
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36  INTELLIGENCE  PARAGRAPH  OF  SITREP 

1.  Enemy  Situation 

a.  Units  in  Contact 

b.  Enemy  Reserves  That  Affect  Local  Situation 

c.  Brief  Description  of  Enemy  Activity  During  Period  of  Report 

d.  Brief  Estimate  of  Enemy  Strength,  Materiel,  Morale,  and  His 
Estimate  of  Our  Situation 

e.  Conclusions  Covering  Courses  of  Action  Open  to  the  Enemy 
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37D  INTELLIGENCE  ESTIMATE* 


1.  Mission 

2.  The  Area  of  Operation 

a.  Weather 

(1)  Existing  Situation 

(2)  Effect  on  Enemy  Courses  of  Action 

b.  Terrain 

(1 )  Existing  Situation 

(a)  Observation  and  Fire 

(b)  Concealment  and  Cover 

(c)  Obstacles 

(d)  Key  Terrain 

(e)  Avenues  of  Approach  into  Our  Postion 

(2)  Effect  on  Enemy  Courses  of  Action 

(3)  Effect  on  Our  Course  of  Action 

3.  Enemy  Situation 

a.  Dispostions 

b.  Composition 

c.  Strength 

(1)  Committed  Forces 

(2)  Reinforcements 

(3)  Air 

(4)  Nuclear  -  Biological  -  Chemical 

d.  Recent  and  Present  Significant  Activities 

e.  Peculiarities  and  Weaknesses 

(1)  Personnel 

(2)  Intelligence 

(3)  Operations 

(4)  Logistics 

(5)  Civil  Affairs 

(6)  Personalities 

*This  format  is  only  used  by  players  within  a  populated  G2  module.  The 
format  is  self-explanatory  and  is  to  be  used  as  a  guideline  by  the  player 
for  producing  an  intelligence  estimate. 
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37D  INTELLIGENCE  ESTIMATE  (cont.) 

4.  Enemy  Capabilities 

a.  Enumeration 

b.  Analysis  and  Discussion 

(1)  Attack 

(2)  Defend 

(3)  Delay 

(4)  Reinforce 

(5)  Withdraw 

(6)  Air 

(7)  Nuclear 

5.  Counterintelligence 

a.  Enemy  Intelligence 

1.  Ground  Surveillance  and  Reconnaissance 

2.  Aerial  Surveillance  and  Reconnaissance 

3.  Signal  Intelligence 

4.  Guerrillas/Insurgents 

5.  Espionage 

b.  Sabotage 

c.  Subversion 


6.  Conclusions 

a.  Utilization  of  Terrain 

b.  Probable  Courses  of  Action 

c.  Vulnerabilities 
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38D  INTELLIGENCE  ANNEX* 


1.  Summary  of  Enemy  Situation 

2.  Essential  Elements  of  Information 

a.  Essential  Elements  of  Information 

b.  Other  Intelligence  Requirements 

3.  Intelligence  Acquisition  Tasks 

a.  Orders  to  Attached  and  Subordinate  Units 

(1)  1st  BDE 

(2)  2nd  BDE 


(n)  EWIOC 

4.  Measures  for  Handling  Personnel,  Documents,  and  materiel 

5.  Documents  and/or  Equipment  Required 

a.  Maps 

b.  Photographic 

6.  Counterintelligence 

7.  Reports  and  Distribution 

8.  Miscellaneous  Instructions 


*This  format  is  only  used  by  players  within  a  populated  G2  module.  The 
format  is  self-explanatory  and  is  to  be  used  as  a  guideline  by  the  players 
producing  an  Intelligence  Annex. 
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39  REQUEST  BY  INTELLIGENCE  STAFF* 
A 

1 .  Proposed  Release  1 . 

2.  Concur  _  2. 

Nonconcur 

(Added  to  a  completed 
Frag  Order  ( INTELL ) ) 


*Request  A  is  forwarded  to  the  command  module  for  a  decision  when  the 
content  of  the  Frag  Order  (INTELL)  broaches  thresholds  as  established 
by  the  commanders  guidance  or  delegated  authority. 

Request  B  is  for  use  by  a  populated  G2  module  when  initiating  a  fraq 
order  not  within  its  purview.  The  message  is  sent  to  the  staff  module 
having  staff  cognizance. 

Request  C  is  for  use  by  the  G2  module  when  a  proposed  frag  order  requires 
a  "chop"  from  another  staff  module. 


B 

Please  Execute 

Concur 

Nonconcur 

(Added  to  a  com¬ 
pleted  Frag 
Order) 


C 

Please  Review 
Concur  _  Nonconcur 
(Added  to  a  com¬ 
pleted  Frag  Order 
(INTELL) 


1 . 
2. 
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40  RESPONSE  TO  REQUEST 

The  responses  to  request  B  consists  of  the  information  copy  of 
the  Frag  Order  in  question  if  accepted  by  the  G2  or  the  return  of  the 
request  if  not. 

The  response  to  request  C  consists  of  the  request  including  the 
completed  Frag  Order  (I)  with  concurrence  or  non-concurrence  filled  in 
as  appropriate  (see  39). 

The  response  to  a  query  is  the  appropriate  Class  4  event. 
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41  BRIGADE/BATTALION  INTSUM 


1.  Summary  of  Enemy  Activity 

a.  Ground 

b.  Trace  of  Forward  elements 

c.  Potential  Targets  for  Nuclear  Attack 

d.  Nuclear  Acti vi ty 

e.  Chemical/Biological  Activity 

f.  Air  Activity 

g.  Other 

2.  Enemy  Personnel/Equipment  Losses 

a.  KIA 

b.  POW 

c.  Equipment  Destroyed/Captured 

3.  Counter  Intelligence 

4.  Obstacles/Barriers 

5.  Unit  Identifications 

6.  Enemy  Movements 

7.  Estimated  Number  and  Type  Vehicles 
0.  Weather 

9.  Capabilities/Vulnerabilities 
10.  Conclusions 
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42  SHELL  REPORT 


1.  Reporting  Unit 

2.  Location  of  Observer 

3.  Azimuth  of  Attack 

4.  Time  of  Attack 

5.  Area  Attacked 

6.  Type  Delivery 

7.  Nature  of  Attack 

8.  Number  of  Rounds 

9.  Flash-to-Bang  Time  (SEC) 

10.  Damage 
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43  SPOT  REPORT* 


Jn^n^ource 

ASA 

SOTAS 

RPV 

GSR 

UGS 

FO 

P/H 

TIME 

m 

X 

m 

X 

X 

H 

LOCATION 

X 

X 

X 

X 

X 

X 

X 

DIR  MOVE 

X 

X 

X 

X 

RATE  MOVE 

X 

X 

X 

UNIT  SIZE 

X 

■ 

UNIT  TYPE 

X 

m 

#  TANKS 

X 

X 

m 

#  APC's 

X 

X 

n 

#  ARTY  TUBES 

X 

X 

wm 

#  UNK  VEHICLES 

X 

X 

X 

X 

X 

m 

A  TROUPS 

X 

X 

X 

n 

UNIT  ID 

n 

X 

D 

RECEIVING 

ELEMENT 

DIV 

m 

DIV/ 

BDE 

BN 

BDE/ 

BN 

BDE/ 
BN/DI  V 

BDE/ 

DIV 

♦Reports  generated  by  division  assets  within  BOG.  Table  indicates  type 
info  forwarded  by  each  "sensor"  (from  "fource"  model).  Only  those 
reports  forwarded  to  division  will  be  forwarded.  Others  will  be  used 


i  n  =44. 

FO 

FORWARD  OBSERVER/RECON 

UGS  = 

UNATTENDED  GROUND  SENSOR 

GSR  = 

GROUND  SURVEILLANCE  RADAR 

RPV  = 

REMOTELY  PILOTED  VEHICLE 

SOTAS  = 

STAND  OFF  TARGET  ACQUISITION  SYSTEM 

ASA  = 

ARMY  SECURITY  AGENCY 

P/H  = 

PRISONER  OF  WAR/HUMAN  INTELLIGENCE 

.  It.  .  L  .  —  .3^^ 
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44  COMBAT  INTELLIGENCE  REPORT* 


1. 

Ti  me 

2. 

Locati on 

3. 

Di  recti  on 

of  Movement 

4. 

Rate  of  Movement 

5. 

Unit  Size 

6. 

Unit  Type 

7. 

Number  of 

Tanks 

8. 

Number  of 

APCs 

9. 

Number  of 

Arty  Tubes 

10. 

Number  of 

Unknown  Vehicles 

11. 

Number  of 

Troops 

*BN/BDE  has  several  sensors  that  submit  "spot  reports" 
in  the  format  of  #443.  These  reports  from  SOTAS,  rpv 
other  sources  will  be  processed/aggregated  at  brinade 
intelligence  is  above  a  certain  threshold  this  report 
to  division  through  the  ASAC. 


directly  to  them 
,  GSR,  UGS  and 
If  the  resultant 
will  be  forwarded 


45  POST  STRIKE  DAMAGE  REPORT* 


CONVENTIONAL* 

1.  Estimated  Percentage  of  Target  Area  Damaged 

2.  Estimate  of  Personnel  Casualties 

3.  Estimate  of  Equipment  Losses 

4.  Estimate  of  Units  Effectiveness 

NUCLEAR** 

1.  Air/Ground  Burst 

2.  Location  of  Ground  Zero 

3.  Estimated  Percentage  of  Target  Area  Damaged 

4.  Estimate  of  Personnel  Casualties 

5.  Estimate  of  Equipment  Losses 

6.  Estimate  of  Unit  Effectiveness 

7.  Effects  on  Terrain 


*Format  derived  to  obtain  timely  assessment  of  enemy  capabilities  after 
an  indirect  weapon  engagement.  Tasking  accomplished  by  G2  and  results 
reported  to  G2.  G2  retransmits  results  to  G3/FSE  for  informational 
purposes. 

**Format  derived  to  facilitate  post  strike  analysis  by  the  FSE.  G2 
tasks  subordinate  units  for  the  collection  of  this  information.  Units 
report  observable  attributes  to  G2  who  in  turn  retransmits  to  FSE. 

FSE  conducts  post  strike  analysis  I AW  FM  101-31-1. 


46  ESTIMATE  OF  ENEMY  STRENGTH/DISPOSITION 


1.  Composition  and  Disposition 

a.  Type  Unit 

b.  Location 

c.  Organization 

2.  Strength  (by  unit  identified) 

3.  Tactics 

4.  Logistics 

5.  Combat  Effectiveness 

a.  Overall 

b.  By  unit  identified 
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47  AGGREGATE  TARGET  L1ST  (INT£LLIG_ENCE)^ 


1  Description 

2.  Location 

3.  Evaluation/Source 

4.  Remarks 


*Sam'e  Information  "is  repeated  for  each  target. 


49 D  CORPS  FRAG  ORDER  (INTELLIGENCE)* 

1.  Mission  Number 


2.  DTG  of  Need 

3.  Subject/Description 

4.  Location 

5.  Task 

6.  Change  in  EEI 


*This  format  is  used  by  the  controller  to  interject  investigator 
objectives  into  the  play  of  the  game. 


DUERY  BY  OPERATIONS  STAFF* 


1.  Message  Required  _ _ 

2.  DTG  of  Need 

3.  Required  of  all  units  (Yes 

4.  Specific  Battalion 


No  _ ;  if  no  complete  4) 


*The  following  lists  indicates  the  allowable  queries  for  the  G3  module. 


Class  3 

60.  Unit  Prog  Rpt 
62.  EOOB 

65.  Bde/Bn  SITREP 
67.  AVN  Sortie  Status 


Class  2 

Arty  SITREP 
Tgt  List  (Arty) 

FU  FS  CAP 

EU  FS  CAP 

PR  for  FS 

FSE  Spt  Status 

BDE  INTSUM 

Est  of  En  Strength/ 

Disp. 

Tgt  List  (I) 

Bde/Bn  PDS 
CAPE  Rpt 
PR  for  Log  Spt 


52  FRAG  ORDER  (OPERATIONS) 
OPERATIONS 


1.  Frag  Order  Number 

2.  Enemy  Situation 

3.  Friendly  Situation 

4.  Any  Change  to  Task  Organization 

5.  Orders  to  Subordinate  Units 

6.  Fire  Support  Considerations 

7.  Coordinating  Instructions 

ELECTRONIC  WARFARE* 

1 .  Frag  Order  Number 

2.  Friendly  Situation 

3.  Any  Change  to  Task  Organization 

4.  EW  Mission  Priori ty 

5.  Any  Change  to  EW  Target  Priority  List 

6.  Coordinating  Instructions 


*The  EW  Frag  Order  is  forwarded  to  the  ASAC  for  compliance. 
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53D  DIVISION  SITREP* 


1.  Enemy  Situation 

a.  Units  in  Contact 

b.  Enemy  Reserves  that  Affect  Local  Situation 

c.  Brief  Description  of  Enemy  Activity  durinq  Period  of  Report 

d.  Brief  Estimate  of  Enemy  Strength,  Materiel,  Morale  and  his 
Estimate  of  our  Situation 

e.  Conclusions  Covering  Courses  of  Action  Open  to  Enemy 

2.  Friendly  Situation 

a.  Location  of  Forward  Elements 

b.  Location  of  Units/Headquarters/Boundaries 

c.  Location  of  Adjacent  Units/Support  Troops 

d.  Brief  Description  and  Results  of  Operations  durinn  Period  of 
Report 

e.  Noneffective  Units 

3.  Administration-General  Statement  as  it  Effects  Tactical  Situation 

4.  General  Information  not  Covered  Elsewhere 

5.  Commander's  Evaluation  (Complete  When  Directed) 


*This  SITREP  is  sent  by  a  populated  G3  to  corps.  It  is  an  aggregate  of 
reports  from  subordinate  brigades,  DIV  ARTY,  and  other  maneuver  units 
under  the  direct  control  of  the  division.  Some  "CAPE"  type  information 
will  be  included  in  paragraph  3. 


54  NUCLEAR  WARNING  ORDER 


0.  Nuclear  Warning  Order  Number 
A.  Code  Word  (=5>  Nuclear  Strike) 

D.  DTG  of  Burst  +  DTG  of  Cancellation 
F.  Desired  Ground  Zero 

H.  Air/Surface  Burst 

I.  MSD  1,  2,  3  in  Hundreds  of  Meters 

Y.  Left  and  Riqht  Radial  Lines 

Z.  Effective  Wind  Speed 

ZI.  Effective  Wind  Speed/Downwind  Distance  I,  II,  Cloud  Radius 


j 


1 

i 

i; 


55  AIR  DEFENSE  WARNING* 


1 .  Ai r  Defense  Warning 

2.  Direction  of  Attack 

3.  Size  of  Attack 

4.  Predicted  Target 


*Issuance  of  this  warning  to  subordinate  units  may  reduce  their  combat 
effecti veness . 


56  REQUEST  FOR  RF^ERVlS* 


1.  Concur  _  Non-concur  _ 

2.  Frag  Order  Number 

3.  Enemy  Situation 

4.  Friendly  Situation 

5.  Orders  to  Corps  Reserves 

6.  Fire  Support  Considerations 

7.  Coordinating  Instructions 


I 


*This  format  is  used  by  the  G3  module  to  request  commitment  of  the 
corps  reserves.  The  Frag  Order  is  sent  to  corps  where  it  is  acted 
upon  by  the  controller. 
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570  OPERATIONS  PLAN* 


Task  Organization 

1.  Situation 

a.  Enemy  Forces 

b.  Friendly  Forces 

c.  Attachments  and  Detachments 

2.  Mission 

3.  Execution 

a.  Concept  of  Operation 

(1)  Maneuver 

(2)  Fires  (Air/Arty/NGF/Nucl ear ) 

b.  1st  Brigade 

c.  2nd  Brigade 

d.  3rd  Brigade 

e.  Fire  Support 

(1 )  Field  Artil lery 

(a)  General 

1_  Priority  of  Fires 
2^  Counter  Priority 

(b)  Organization  for  Combat 

(c)  Special  Instructions 

(2)  Close  Air  Support 

(a)  General 

(b)  Distribution  for  Planning  Purposes 

(c)  Special  Instructions 

(3)  Naval  Gunfire 

(a)  General 

(b)  Allocation  of  Naval  Gunfire  Support 

(c)  Special  Instructions 

*This  format  is  onl7  used  by  players  within  a  populated  G3  module. 
The  format  is  self-explanatory  and  is  to  be  used  as  a  guideline  by 
the  players  for  producing  an  operations  plan  as  required. 


57D  OPERATIONS  PLAN  (Continued) 

(4)  Nuclear 

(a)  General 

(b)  PNL 

(5)  Chemical 

(a)  General 

(b)  PCL 

(6)  Fire  Support  Coordinating  Instructions 

(a)  Fire  Planning  and  Control 

(b)  Safety 

f.  Air  Defense  Artillery 

g.  Engineer 

h.  Division  Troops 

i.  Division  Support  Command 

j.  Reserve 

k.  Coordinating  Instructions 

4.  Service  Support 

5.  Command  and  Signal 


ANNEXES: 

DISTRIBUTION: 
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58D  OPERATIONS  ESTIMATE* 

1.  Mission 

2.  The  Situation  and  Courses  of  Action 

a.  Considerations  Affecting  Possible  Courses  of  Action 

(1)  Characteristics  of  the  area  of  operation 

(a)  Weather 

(b)  Terrain 

(c)  Other 

(2)  Enemy  Situation 

(3)  Friendly  Situation 

(4)  Relative  combat  Power 

b.  Enemy  Capabilities 

c.  Own  Courses  of  Action  (C/A) 

3.  Analysis  of  Opposing  Courses  of  Action 

a.  C/A  1  versus  Enemy  Capabilities  plus  other  selected  consider¬ 
ations  -  (To  determine  the  Advantages  and  Disadvantages  and 
develop  a  General  Scheme  of  Maneuver) 

b.  C/A  2  versus  Enemy  Capabilities  plus  other  selected  considera¬ 
tions  -  (To  determine  the  Advantages  and  Disadvantages  and 
develop  a  General  Scheme  of  Maneuver) 

4.  Comparison  of  Own  Courses  of  Action 

C/A  1  --  Significant  Advantages  --  Significant  Disadvantages 
C/A  2  --  Significant  Advantages  --  Significant  Disadvantages 
Discussion:  Compare  C/A  1  and  C/A  2 
Conclusion:  Course  of  action  to  select  for  adoption 

5.  Decision  (Recommendation).  Scheme  of  maneuver  based  on  selected 
C/A 


*This  format  is  only  used  by  players  within  a  populated  G3  model. 
The  point  is  self-explanatory  and  is  to  be  used  as  a  guideline  by 
the  players  for  producing  an  operations  estimate.  Intelligence  in¬ 
puts  will  be  required. 
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59  INITIAL  ENEMY  CONTACT 

1.  Engaged/DTG 

2.  Location 

3.  Estimated  Size  of  Enemy  Force 

4.  Type  Fire  Receiving 

5.  Direction  and  Distance  Fire  Coming  From 

6.  Friendly  Casualties 

7.  Activity 

8.  Required  Support 


n.RQ 


60  UNIT  PROGRESS  REPORT* 


1. 

IN  CONTACT 

Location  of  Forward  Units 

1. 

NOT  IN  CONTACT 

Location  of  Forward  Units 

2. 

Location  of  Unit  HQ/Boundaries 

2. 

Activity/DTG 

3. 

Enemy  Casualties 

3. 

Remarks 

4. 

Enemy  Equipment  Destroyed 

5.  Personnel  Losses 

6.  Shortages  Which  Effect  Unit/MSN 

a.  Personnel 

b.  Equipment 

c.  POL 

d.  Ammunition 

7.  Activity/DTG 

8.  Combat  Effectiveness 


*Reports  will  be  forwarded  on  basis  of  enemy  contact.  Activity  descrip¬ 
tor  will  be  filled  in  accordingly,  e.g.,  -  (in  contact)  -  engaging,  ad¬ 
vancing,  retreating,  enemy  withdrew,  withdrew  from  enemy,  seized  objec¬ 
tive  -  (not  in  contact)  -  begin  movement,  passed  check  point,  passed 
phase  line,  passed  line  of  departure,  assembly  area,  closed  new  position. 


61  LOSS  CONTACT  WITH  FRIENDLY  UNIT* 


1 .  Loss  Contact 

2.  Identification  (Lost  Unit) 

3.  Last  Known  Location  (Lost  Unit) 

4.  Was  Unit  in  Contact? 

5.  Was  Unit  Moving?  (Direction/Rate) 

6.  Action  Being  Taken 

7.  Support  Required  (Aerial  Observor,  etc.) 


*This  event  may  be  triggered  by  the  controller  or  may  be  part  of 
initialization  data. 


62  ENEMY  ELECTRONIC  ORDER  OF  BATTLE 


1.  Voice  Communication  Nets 

a.  Unit 

b.  Location 

c.  Frequency 

d.  Net  Usage 

e.  Frequency  of  Use 

2.  Multichannel  Communication  Nets 

a.  Units 

b.  Location 

c.  Net  Usage 

d.  Frequency 

3.  Non- Communication  Emitters 

a.  Unit 

b.  Purpose  of  Emitter 

c.  Location 

d.  Type  Emitter 

e.  Frequency 


63  REQUEST  BY  OPERATIONS  STAFF* 


A 

Proposed  Release 
Concur  __  Nonconcur  _ 
(Added  to  a  completed 
Frag  Order  (OPS) ) 


B 

1 .  Please  Execute 

2.  Concur  _ 

Nonconcur  __ 

(Added  to  a  com¬ 
pleted  Frao  Order) 


C 

1 .  Please  Review 

2.  Concur  _  Nonconcur  _ 
(Added  to  a  completed 

Frag  Order  (OPS)) 


♦Request  A  is  forwarded  to  the  command  module  for  a  decision  when  the 
content  of  the  Frag  Order  (OPS)  broaches threshol ds  as  established  by 
the  commanders  guidance  or  delegated  authority. 

Request  B  is  for  use  by  a  populated  G3  module  when  initiating  a  frag 
order  not  within  its  purview.  The  message  is  sent  to  the  staff  module 
having  staff  cognizance. 

Request  C  is  for  use  by  the  G3  module  when  a  proposed  frag  order  requires 
a  "chop"  from  another  staff  module. 


64  RESPONSE  TO  REQUEST 

The  response  to  Request  B  consists  of  the  information  copy  of 
the  Frag  Order  (OPS)  if  accepted  by  the  G3  or  the  return  of  the  request 
if  not. 

The  response  to  Request  C  consists  of  the  request  including  the 
completed  Frag  Order  in  question  with  concurrence  or  non-concurrence 
filled  in  as  appropriate  (see  63). 

The  response  to  a  query  is  the  appropriate  Class  4  event. 


65  BRIGADE/ BATTALION  SITREP* 

1.  Enemy  Situation 

a.  Units  In  contact 

b.  Eneniy  Reserves  That  Affect  Local  Situation 

c.  Brief  Description  of  Enemy  Strenath,  Materiel,  Morale  and 
his  Estimate  of  our  Situation 

d.  Conclusions  Covering  Courses  of  Action  Open  to  Enemy 

2.  Friendly  Situation 

a.  Location  of  Forward  Elements 

b.  Location  of  Units/Headquarters/Boundaries 

c.  Location  of  Adjacent  Units/Support  Troops 

d.  Brief  Description  and  Results  of  Opeiations  During  Period 
Oi  Report 

e.  Non-effective  Units 

3.  Administration  -  General  Statement  as  it  Effects  Tactical 
Si tuati on 

4.  General  Information  not  Covered  Elsewhere 

5.  Commander's  Evaluation  (Complete  When  Directed) 


*This  SITREP  is  sent  to  G3  by  subordinate  brigades  and  other  maneuver 
units  under  the  direct  control  of  the  division.  Reporting  centers 
must  aggregate  information  from  task  organized  infantry  units.  Para¬ 
graphs  1  &  2  may  require  simulated  historical  file.  This  would 
allow  for  changes  to  be  reported.  Some  "CAPE"  type  info  will  be  in¬ 
cluded  in  paragraph  3.  Controller  will  provide  info  under  4  and  5. 
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66  AIR  DEFENSE  ALERT* 

1.  Air  Defense  Warning 

2.  Weapons  Control 

3.  Direction  of  Attack 

4.  Size  of  Attack 


*Air  Defense  Artillery  units  will  forward  this  message  (based  upon  radar 
reports)  to  G3.  The  G3  will  disseminate  message  to  affected  friendly 
uni ts . 
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67  ORGANIC  AVIATION  SORTIE  STATUS 


1 . 
2. 

3. 

4. 

5. 

6. 

7. 


Period  Coverage  FM  DTG  to  DTG 

Type  Mission*  (Gunsh i p/Troop  Li ft/Resupply/MEDEVAC ) 

Number  Missions  Scheduled 
Number  Missions  Completed 
Number  of  Missions  Cancelled 

Results*  (IN  PE RS/ EQUIP CASUALTIES/TROOPS  MOVED/CARGO  MOVED/ 
MEDEVACS) 

Quantity  of  Aircraft 

a.  Type  Gunship: 

b.  Transport: 

c.  Resupply: 

d.  MEUEVAC: 


*This  format  is  used  to  indicate  army  aviation  sortie  status.  Para¬ 
graph  2  and  6  will  be  applicable  to  specific  type  missions  and  mission 
resul ts . 


QUERY  ON  AIR  DEFENSE  WARNING 


s 


71 D  CORPS  FRAG  ORDER  (OPERATIONS)* 

Operations 

1 .  Frag  order  number 

2.  Enemy  Situation 

3.  Friendly  Situation 

4.  Any  Change  to  Task  Organization 

5.  Orders  to  Subordinate  Units 

6.  Fire  Support  Considerations 

7.  Coordinating  Instructions 

Electronic  Warfare 

1 .  Frag  order  number 

2.  Friendly  Situation 

3.  Any  change  to  task  organization 

4.  EW  mission  priorities 

5.  Any  change  to  EW  target  priority  list 

6.  Coordinating  instructions 


♦These  formats  are  used  by  the  controller  to  interject  investigator 
objectives  into  the  play  of  the  game. 


72D  OPERATIONS  SPECIAL  ESTIMATE/ANNEX* 


A.  Army  Aviation 

1.  Situation 

a.  Enemy  forces 

(1)  Ground  forces 

(2)  Enemy  air  defense 
capabilities 

b.  Friendly  forces 

c.  Attachment/detach¬ 
ments 

2.  Mission  (aviation  support 
operations) 

3.  Execution 

a.  Concept  of  operations 

b.  Aviation  unit  tasks 

(1)  MED  EVAC 

(2)  Resupply 

(3)  Trooplift 

(4)  Gunship 

h.  Priority  of  support 

g.  Coordinating  instruc¬ 
tions 

(1)  FAC  Operations 

(2)  VFR  air  traffic 
control 

4.  Service  support 

a.  Ordnance 

b.  POL 

c.  Maintenance 

d.  Airbases 

5.  Command  and  signal 


B.  Communications 

1.  Situation 

a.  Enemy  situation 

b.  Friendly  situation 

c.  Area  of  operations 

(1)  Terrain 

(2)  Weather 

(3)  Existing  Comm 

2.  Mission  (comm  support  op¬ 
erations) 

3.  Execution 

a.  Concept  of  operations 

b.  Communication  unit  task 

(1)  Tactical  radio 

(2)  Multichannel 

(3)  Wire  and  cable 

(4)  Messenger 

h.  Priority  of  support 

g.  Coordinating  instruc¬ 
tions 

(1)  MI J I  Reports 

(2)  EW 

(3)  CEOI 

4.  Service  support 

5.  Command  and  signal 


72D  (CONTINUED) 

C.  Engineer 

1.  Situation 

a.  Enemy  situation 

b.  Friendly  situation 

c.  Area  of  operations 

(1)  Terrain 

(2)  Weather 

2.  Mission  (engineer  support  operations) 

3.  Execution 

a.  Concept  of  operations 

b.  Engineer  unit  tasks 

(1)  Barriers 

(2)  Obstacles 

(3)  Mine  fields 

(4)  Construction 
h.  Priority  of  support 

g.  Coordinating  instructions 

4.  Service  support 

5.  Command  and  signal 


♦These  formats  are  only  used  by  players  within  a  populated  G3  model. 
The  formats  are  proposed  in  advance  and  issued  by  the  controller 
from  record  as  required  for  planning  purposes. 
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80  QUERY  BY  COMBAT  SERVICE  SUPPORT  ELEMENT* 

1.  Message  required 

2.  DTG  of  need 

3.  Required  of  all  units  (YES  _ ;  NO _ ;  if  no  complete  4) 

4.  Specific  battalions 

a. 

b. 

c. 

d. 

e. 


*The  following  lists  indicate  the  allowable  queries  for  the  G1/G4 
module: 


Class  3  Class  2 


91 

Bde/Bn  PDS 

15 

Arty  SITREP 

92 

CAPE  Rpt 

16 

Tgt  List  (Arty) 

93 

PR  for  LOG  Spt 

17 

FU  FS  Cap 

18 

EU  FS  Cap 

24 

PR  for  FS 

26 

FSE  Spt  Status 

41 

Bde/INTSUM 

46 

Est  of  En  Strength/Di sp 

47 

Tgt  List  (I) 

60 

Unit  Prog  Rpt 

62 

EOOB 

65 

Bde/Bn  SITREP 

67 

Avn  Sortie  Status 
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81 D  QUERY  ON  CORPS  FRAG  ORDER  (COMBAT  SERVICE  SUPPORT) 

This  is  a  free  text  query  by  a  populated  G1/G4  of  Corps  (controller) 


82  FRAG  ORDER  (COMBAT  SERVICE  SUPPORT) 

A.  Change  to  Combat  Service  Support  Annex 

1.  Frag  Order  Number 

2.  General 

3.  Materiel  and  Services  (Changes) 

a.  Supply  (Changes  by  Class) 

b.  Transportation 

c.  Services 

d.  Maintenance 

4.  Medical  Evacuation  and  Hospitalization 

5.  Personnel 

6.  Civil  Military  Cooperation 

7.  Miscellaneous 

B.  Medical  Evacuation 

1.  Medevac  Number 

2.  Unit/Callsign 

3.  Location  (Pickup) 

4.  Number  Wounded 

5.  Type  Wounds 

6.  Number  of  Litter  and  Ambulatory 

7.  Tactical  Situation 

8.  Precedence 

9.  Location  (Delivery) 

C.  Resupply 

1.  Resupply  Number 

2.  Unit/Callsign 

3.  Location  (Delivery) 

4.  DTG  of  Delivery 

5.  LZ/Free  Drop 

6.  Tactical  Situation 

7 .  Precedence 

8.  General  List  of  Items 


D-76 


82  FRAG  ORDER  (COMBAT  SERVICE  SUPPORT)*  (Continued) 
D.  Troop  Lift 

1.  Troop  Lift  Number 

2.  Unit/Callsign 

3.  Location  (Pickup) 

4.  Number  of  Troops /Type  Equipment 

5.  Tactical  Situation  (Pickup) 

6.  DTG  (Pickup) 

7.  Location  (Delivery) 

8.  DTG  (Delivery) 

9.  Tactical  Situation  (DROP) 

10.  Precedence 


♦Formats  B,  C,  D  are  in  response  to  requests  from  subordinate,  adjacent 
or  higher  headquarters.  The  G4  must  determine  who  and  how  request  will 
be  handled  and  transmit  this  message  to  that  unit  with  copy  to  requestor 
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830  DIVISION  PERSONNEL  DAILY  SUMMARY* 

1.  Strength  (Assigned/Authorized) 

2.  Daily  Losses 

a.  Casualties  (KIA/WIA/MIA/Captured) 

b.  Non-battle 

3.  Cumulative  Losses  from  DTG 

a.  Casualties  (KIA/WIA/MIA/Captured) 
b  Non-battle 

c.  Days  in  Combat  (Per  Battalion) 

4.  Gains  (Replacements/Returned  to  Duty) 

5.  Prisoners  of  War 

a.  Captured 

b.  Evacuated 

c.  On  Hand 

d.  Total  Taken  from  DTG 

6.  Remarks 


♦This  format  aggregates  those  input  by  subordinate  units.  It  is  for¬ 
warded  to  Corps  only  by  a  populated  G1/G4  module. 
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84D  PERIODIC  LOGISTIC  REPORT* 


1.  Logistic  situation  at  end  of  period 

2.  Supply 


a. 

Supported  strength 

b. 

Status  of  supply 

c. 

Local 

procurement 

d. 

Miscellaneous 

Service 

a. 

Transportation 

(1) 

Highway 

(2) 

Air 

(3) 

Rail 

(4) 

Water 

(5) 

Pipel ine 

(6) 

Supply  movement 

(7) 

Personnel  movement 

b. 

Construction 

c. 

Installations 

d. 

Miscellaneous 

4.  Maintenance 

5.  Miscellaneous 

a.  Boundaries 

b.  Hdq 

c.  Changes  in  assignment 

d.  Protection 

e.  Plans  and  orders 

f.  Other  logistic  matters 


*Format  only  used  by  a  populated  G1/G4.  It  provides  quidance  to  the 
players  to  enable  them  to  produce  the  required  report. 
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85D  PERSONNEL  REQUISITION 

1.  Present  readiness  condition  _ _ 

2.  Personnel  required 

a.  Rank 

b.  Quantity 

c.  MOS 

3.  Continuous  days  unit  in  combat 

4.  Losses  by 

a.  KIA 

b.  WIA 

c.  Non-battle 


d.  Other 

5.  Expected  readiness  condition  if  augmented 


k 


860  and  93  REQUEST  FOR  LOGISTICAL  SUPPORT* 

A.  Medical  Evacuation** 

1 .  Locati on 

2.  Number  of  Wounded 

3.  Type  Personnel 

4.  Type  Wounds 

5.  Number  of  Litter  and  Ambulatory 

6.  Tactical  Situation 

7.  Precedence 


B.  Resupply* 

1.  Resupply 

2.  Location 

3.  DTG  of  Delivery 

4.  LZ/Free  Drop  (if  by  Helo) 

5.  Precedence 

6.  Tactical  Situation 

7.  List  of  Items  (Item/Qty) 

C.  Troop  Lift* 

1.  Troop  Lift 

2.  Pickup  Location 

3.  Number  of  Troops 

4.  DTG  of  Pickup 

5.  Tactical  Situation 

6.  Delivery  Location 

7.  DTG  of  Delivery 

8.  Tactical  Situation 

9.  Precedence 


*May  be  used  for  immediate  (86,  86D)  or  preplanned  (93)  logistical 
requests. 

**Used  only  for  immediate  requests  (86,  86D). 
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87D  COMBAT  SERVICE  SUPPORT  ESTIMATE* 


1.  Mission 

2.  The  Situation  and  Courses  of  Action 

a.  Considerations  Affecting  the  Possible  Course  of  Action 

(1)  Operations  to  be  supported 

(2)  Characteristics  of  the  Area  of  Operations 

(3)  Enemy  Situation 

(4)  Own  Situation 

(a)  Tactical 

(b)  Personnel 

(c)  Logistic 

(d)  Civil-Military  Operations 

b.  Anticipated  Difficulties  or  Difficulty  Patterns 

c.  Own  Course  of  Action 

3.  Analysis  of  Opposing  Courses  of  Action 

4.  Comparison  of  Own  Course  of  Action 

5.  Recommendations 


♦This  format  is  only  used  by  players  within  a  populated  G1/G4  module. 
The  format  is  self-explanatory  and  is  to  be  used  as  a  guideline  by 
the  players  for  producing  a  CSS  estimate,  as  required. 
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88D  COMBAT  SERVICE  SUPPORT  ANNEX* 


1.  General 

2.  Materiel  and  Services 


Supply 

0) 

Cl 

I 

(2) 

Cl 

II 

(3) 

Cl 

III 

(4) 

Cl 

IV 

(5) 

Cl 

V 

(6) 

Cl 

VI 

(7) 

Cl 

VII 

(8) 

Cl 

VIII 

(9) 

Cl 

IX 

(10) 

Air 

~  Resupply 

b.  Transportation.  Traffic  Circulation  and  Control 

c.  Services 

d.  Maintenance.  Priority  of  support  to  _ __ 

3.  Medical  Evacuation  and  Hospitalization 

4.  Personnel 

5.  Civil -Military  Cooperation 

6.  Miscellaneous 


*This  format  is  only  used  by  players  with  a  populated  G1/G4  module 
The  format  is  self-explanatory  and  is  to  be  used  as  a  guideline  by 
the  players  for  producing  a  CSS  annex,  as  required. 


REQUEST. BY  COMBAT  SERVICE  SUFI  ORT  STAFF* 


A 
— *» 

1.  Proposed  Release 

2.  Concur  _  Nonconcur 

(Added  to  a  completed 

Frag  Order  (CSS)) 


Execute 


Concvr  _ 

Nonco^.ur 

(Added 

pleted 


a  corn¬ 
ea  Order) 


C 

1.  Please  Review 

\2.  Concur  _  Nonconcur 

(Added  to  a  completed 

Frag  Order  (CSS)) 

\ 


♦Request  A  is  forwarded  to  the  command  module  for  a  decision  when 
the  context  of  the  Frag  Order  (CSS)  broaches  thresholds  as  established 
by  the  commander's  guidance  or  delegated  authority. 

Request  B  is  for  use  by  a  populated  G1/G4  module  when  initiating  a 
Frag  Order  not  within  its  purview.  The  message  is  sent  to  the  staff 
module  having  staff  cognizance. 

Request  C  is  for  use  by  the  G1/G4  module  when  a  proposed  FVaq  Order 
requires  a  "chop"  from  another  staff  module. 


D-84 


90  RESPONSE  TO  REQUEST 

The  response  to  Request  B  consists  of  the  information  copy  of  the 
Frag  Order  (CSS)  if  accepted  by  the  G1/G4  or  the  return  of  the  re¬ 
quest  if  not. 

The  response  to  Request  C  consists  of  the  request  includinq  the 
completed  Fraq  Order  in  question  with  concurrence  or  non-concurrence 
filled  in  as  appropriate  (see  89). 


The  response  to  a  query  is  the  appropriate  Class  4  event. 


91  BRIGADE/BATTALION  PERSONNEL  DAILY  SUMMARY 

1.  Strength  (Assigned/Authorized) 

2.  Daily  Losses 

a.  Casualties  (KIA/WIA/MIA/Captured) 

b.  Non-Battle 

3.  Cumulative  Losses  From  DTG 

a.  Casualties  (KIA/WIA/MIA/Captured) 

b.  Non-Battle 

c.  Days  in  Combat  (Per  Battalion) 

4.  Gains  (Replacements/Returned  to  Duty) 

5.  Prisoners  of  War 

a.  Captured 

b.  Evacuated 

c.  On  ,!and 

d.  Total  Taken  From  DTG 

6.  Remarks 


92  CAPE  REPORT* 


£.  Casualty  Spot  Report 

1.  KIA 

2.  WIA 

3.  MIA 

4.  Non-Battle  Losses 

5.  Administrative  Losses  j 

6.  Assigned  Strength  (OFF/WO)  j 

7.  Assigned  Strength  (ENL)  j 

! 

A.  Report  of  Ammo  used 

1.  Type/Quantity  (Repeat  as  Necessary) 

£_.  Report  of  POL  used 

1.  Type/Quantity  (Repeat  as  Necessary) 

E.  Equipment  Status  Report  (Repeat  as  Necessary) 

1 .  Equipment  Type 

2.  Quantity  Lost/Destroyed  During  Reporting  Period 

3.  Quantity  Inoperable  Because  of  Deficiency 

4.  Quantity  of  "3''  not  Repairable  Because  of  Lack  of  Parts/Assemblies 

5.  Quantity  of  Operable  Assets  on  Hand 


♦Subordinate  units  may  submit  each  report  separately  or  the  the  report 
may  be  issued  in  its  entirety. 
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94  QUERY  ON  FRAG  ORDER  (CSS 

The  format  for  this  message  will  be  the  received  message  with 
notations  indicating  technical  inaccuracies. 
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95D  CORPS  FRAG  ORDER  (COMBAT  SERVICE  SUPPORT)* 


A.  General  Frag 

1.  Frag  Order  Number 
2  General 

3.  Materiel  and  Services  (Changes) 

a.  Supply  (Chanqes  by  Class) 

b.  Transportation 

c.  Services 

d.  Maintenance 

4.  Medical  Evacuation  and  Hospitalization 

5.  Personnel 

6.  Civil  Military  Cooperation 

7.  Miscellaneous 

B.  Medical  Evacuation 

1 .  Medevac  Number 

2.  Unit/Call  Sign 

3.  Location  (Pick  up) 

4.  Number  Wounded 

5.  Type  Wounds 

6.  Number  of  Litter  and  Ambulatory 

7.  Tactical  Situation 

8.  Precedence 

9.  Location  (Delivery) 

C.  Resupply 

1 .  Resupply  Number 

2.  Unit/Call  Sign 

3.  Location  (Delivery) 

4.  DTG  of  Delivery 

5.  LF/Free  Drop 

6.  Tactical  Situation 

7.  Precedence 

8.  General  List  of  Items 

*These  formats  are  used  by  the  controller  to  interject  investigator 
objectives  into  the  play  of  the  game. 


95D  FRAG  ORDER  (CSS)  (Continued) 

D.  Troop  Lift 

1.  Troop  Lift  Number 

2.  Unit/Call  Sign 

3.  Location  (Pick  up) 

4.  Number  of  Troops/Type  Equipment 

5.  Tactical  Situation  (Pick  up) 

6.  DTG  (Pick  up) 

7.  Location  (Delivery) 

8.  DTG  (Delivery) 

9.  Tactical  Situation  (Drop) 

10.  Precedence 


♦Formats  B,  C,  D  reflect  tasking  from  subordinate,  adjacent,  or  higher 
headquarters.  The  G4  must  determine  who  and  how  request  will  be 
handled  and  transmit  this  message  to  that  unit  with  copy  to  corps. 


960  DIVISION  SUPPORT  COMMAND  SITUATION  REPORT* 

1.  Logistics  Situation 

a.  Location  of  Boundaries 

b.  Locations  of  Installations 

c.  Locations  of  Troops 

d.  Transportation 

e.  Service 

f.  Miscellaneous 

2.  Supply 

a.  Supported  Strength 

(1)  Military  Personnel 

(2)  Prisoners  of  War 

(3)  Civilians 

b.  Status  of  Supply 

(1)  Levels 

(Class  of  Supply/Authorized/Issued/On  Hand) 

(2)  Short  Supply  Items 

(Class  of  Supply/Authori zed/ Issued/On  Hand) 

c.  Local  Procurement 
(Description/Quantity/Val ue) 

d.  Miscellaneous 

(1)  Excess 

(2)  Salvage 

(3)  Captured  Materials 

(4)  Supplies 

(5)  Special 

(a)  Publications 

(b)  Exchange  Items 

(c)  Civil  Affairs 

3.  Service 

a.  Transportation 
(1)  Highway 

(a)  Transport  Vehicles 

(Type/Ava i 1 abi 1 i ty/Operabl e/Deadl i ne/Category 
Maintenance) 


□ 
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96D  DIVISION  SUPPORT  COMMAND  SITUATION  REPORT  (Continued)* 

(b)  Tonnage  of  Supplies 

(Number  Vehicles/Number  People/Runs  (Local -Long  Range)) 

(c)  Terminal  Operations 

(Tonnage/Number  Vehicles/Number  Personnel  Loading- 
Unloading/Equipment  Used) 

(2)  Air 

(a)  Transport  Vehicles 

(Type/Avail abi 1 i ty/Operable/Deadl ine/Category 
Maintenance) 

(b)  Tonnage  of  Supplies 

(Number  Vehicles/Number  People/Runs  (Local -Lonq  Ranqe)) 

(c)  Terminal  Operations 

(Tonnage/Number  Vehicles/Number  Personnel  Loading- 
Unloading/Equipment  Used) 

(3)  Rail 

(a)  Transport  Vehicles 

(Type/Avai labil i ty/Operable/Deadl i ne/Category 
Maintenance) 

(b)  Tonnage  of  Supplies 

(Number  Vehicles/Number  People/Runs  (Local -Lonq  Range)) 

(c)  Terminal  Operations 

(Tonnage/Number  Vehicles/Number  Personnel  Loading- 
Unloading/Equipment  Used) 

(4)  Water 

(a)  Transport  Vehicles 

(Type/Avai 1 abi 1 i ty/Operable/Deadl ine/Category 
Maintenance) 

(b)  Tonnage  of  Supplies 

(Number  Vehicles/Number  People/Runs  (Local-Long  Ranqe)) 

(c)  Terminal  Operations 

(Tonnage/Number  Vehicles/Number  Personnel  Loadino- 
Unloading/Equipment  Used) 

(5)  Pipeline 

(6)  Supply  Movement 

(a)  Tonnage 

(b)  Location 

(c)  Destination 


960  DIVISION  SUPPORT  COMMAND  SITUATION  REPORT* 


(7)  Personnel  Movement 

(a)  Number 

(b)  Location 

(c)  Destination 

b.  Construction 

(Project/%  Completed/Project  Operable/ComDletion  Date) 

c.  Installations 

(Installations  not  Covered/Work  Load/Class  of  Work) 

d.  Miscellaneous 

(Real  Estate/Laundry/Bath/Clothing  Exchange/Decontamination) 

4.  Maintenance 

a.  Class  Awaitinn  Maintenance 

b.  Received  during  Period 

c.  Completed  during  Period 

d.  On  Hand  Beginning/End  of  Period 

5.  Miscel laneous 

a.  Boundaries 

b.  Headquarters 

c.  Changes  in  Assignment 

d.  Protection 

e.  Plans  and  Orders 

f.  Other  Logistic  Matters 


*This  format  is  only  used  when  the  G1/G4  is  populated.  It  is  provided 
as  required  by  the  controller  from  record. 


97D  CIVILIAN/MIL  I TARV  OPERATIONS  ESTIMATE/ANNEX* 

1.  Mission 

2.  Situation  and  Considerations 

a.  I n  tel  1  Situation 

(1)  Characteristics  of  AO  and  its  Effect  on  CMO 

(2)  Enemy  Strength/Disposi tions  and  their  Effect  on  CMO 

(3)  Enemy  Capability 

b.  Tactical  Situation 

(1)  Own 

(2)  Possible  Causes  of  Action 

c.  Personnel  Situation 

d.  Logistical  Situation 

e.  Assumptions 

f.  CMO  Situation  and  Nature  of  Operations  to  be  Supported 

g.  Special  Factors 

3.  Analysis 

a.  Government  Functions 

(1)  Civil  Government 

(2)  Public  Safety 

(3)  Public  Health 

(4)  Labor 

b.  Economic  Functions 

(1)  Commerce  and  Industry 

(2)  Food  and  Agriculture 

(3)  Civilian  Supply 

c.  Public  Facilities 

d.  Special  Functions 

4.  Comparison 

a.  Courses  of  Action 

(1)  Advantages 

(2)  Disadvantages 

b.  Di scussion 
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97D  CIVILIAN/MILITARY  OPERATIONS  ESTIMATE/ANNEX*  (Continued) 

5.  Conclusions 

a.  Civil  Affair  Spt 

b.  Tactical  Course  of  Action  Recommendation 

c.  Deficiencies  Requiring  Commander's  Attention 


♦Format  only  used  by  a  populated  G1/G4.  It  is  provided  as  required 
by  the  controller  from  record. 
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DESIGN  NOTE  E 


CLASS  3  EVENTS 


E. 1  GENERAL 

Class  3  events  represent  the  outcome  (i.e.,  class  of  decision 
-variables)  of  internal  staff  action  and/or  interaction  which  affect 
the  battle  outcome  generator  (BOG)  or  tactical  messages  to  corps, 
adjacent  divisions  or  special  staff  officers.  The  defined  Class  3 
events  are  contained  in  Appendix  E-l.  These  events  correspond  to  the 
table  of  Class  3  events  given  in  subsection  4.1.2.  These  interface 
events  allow  the  division  staff  to  task/query  subordinate  units  rep¬ 
resented  within  the  BOG;  keep  senior  commanders  informed  of  the  battle 
within  the  division  area  of  operations  and/or  request  additional  sup¬ 
port  as  necessary,  query  the  special  staff  on  the  current  status  of 
special  purpose  units  organic  to  the  division;  or  provide  tasking  on 
electronic  warfare  or  intelligence  collection  to  the  EWIOC  of  the 
CEWI  battalion. 

•  Class  3  interface  events  will  trigger  battle  (Class  5) 
events  when  the  recipients  of  the  messages  are  rep¬ 
resented  within  the  BOG.  In  some  cases,  they  may 
simply  be  requests  for  additional  information  from  sub¬ 
ordinate  units. 

•  Corps  and  adjacent  divisions  will  not  be  represented 
within  the  BOG.  Hence,  any  Class  3  messages  directed 
to  these  units  will  be  received,  processed,  and  acted 
upon  by  the  control ler(s ) .  Controller  processing  of 
these  Class  3  events  will  include  posting  the  receipt 
time  of  messages  received  from  populated  modules,  filing 
the  tactical  documents  in  record,  and  providing  responses 
as  necessary.  Responses  will  be  delayed  by  the  controller 
to  reflect  realistic  transmission  and  processing  times. 

Specific  design  considerations  for  Class  3  events  are  discussed  below. 

E.2  CLASS  3  EVENTS  WHICH  AFFECT  THE  BOG 

The  first  set  of  Class  3  events  that  will  be  considered  are 
those  which  affect  the  BOG.  The  units  represented  within  the  BOG 
consist  of  all  maneuver  and  fire  support  units  subordinate  to  the 
division  plus  the  engineer  battalion,  signal  battalion.  Army  and 
Air  Force  aviation  elements,  air  defense  elements,  cavalry  squadron, 
and  the  CEWI  battalion. 
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E.2.1  Frag  Orders 


The  first  type  of  Class  3  events  within  this  set  are  frag  orders. 
Frag  orders  contain  one  or  more  tasks  to  be  accomplished  or  implemented 
by  units  within  the  BOG  during  the  execution  of  the  simulation.  Each 
principal  staff  element  (except  the  Command  Group)  may  issue  frag  orders 
to  the  BOG.  Information  copies  of  the  frag  order  are  forwarded  to  corps 
and  adjacent  divisions.  A  frag  order  may  be  issued  by  a  staff  section 
only  within  its  own  area  of  responsibility  (e.g.,  maneuver  elements  and 
priority  of  fires  are  the  G3's  concern  and  intelligence  collection 
tasking  is  within  the  purview  of  the  G2).  This  design  implies  that  the 
commander  does  not  issue  orders  directly  to  subordinate  units  but  does 
so  only  through  his  principal  staff  sections.  The  design  also  dictates 
that  no  individual  task  may  be  executed  within  the  BOG  until  the  entire 
frag  order  is  issued  correctly. 

When  a  populated  staff  module  issues  a  frag  order,  the  BOG  will 
review  the  order  for  technical  accuracy.  In  the  event  an  error  is 
detected,  the  BOG  will  "query"  the  issuing  staff  module.  The  query 
will  be  a  copy  of  the  frag  order  indicating  the  technical  errors.  The 
issuing  staff  modulewill  correct  the  errors  and  resubmit  the  corrected 
frag  order  as  the  response.  The  BOG  will  not  review  the  frag  orders 
for  tactical  considerations. 

Frag  orders  issued  by  simulated  modules  will  be  "edited"  by 
the  same  procedure  as  that  used  with  populated  modules,  but  a  query 
will  not  be  generated  back  to  the  issuing  staff  module.  Instead  the 
simulator  will  make  an  error  stop. 

E.2.2  Warning  Orders 

The  second  type  within  this  set  covers  warning  orders.  The 
G3  module  has  the  capability  to  issue  air  defense  warnings  and  nuclear 
warning  orders  to  subordinate  units  represented  within  the  BOG.  The 
BOG  will  review  these  orders,  in  a  manner  similar  to  the  frag  orders, 
and  disseminate  them  to  concerned  units.  The  dissemination  of  the 
warning  orders  will  probably  result  in  the  reduction  of  combat  effec¬ 
tiveness  for  some  units.  Accordingly,  it  is  incumbent  upon  the  G3 
module,  whether  populated  or  simulated,  to  delineate  to  which  units 
these  warnings  should  be  addressed.  Copies  of  these  warning  orders 
are  also  provided  to  corps  and  adjacent  divisions  for  information  pur¬ 
poses. 

E.2.3  Queries 

The  third  and  final  type  of  Class  3  event  within  this  set  are 
"queries”  which  can  be  generated  by  each  module.  Essentially,  these 
are  requests  for  additional  or  updated  information  on  periodically 
triggered  reports  prepared  within  the  BOG  (e.g.,  BDE/BN  SITREP  or 
BDE  INTSUM)  or  planning  documents  from  special  staff  officers.  Each 


principal  staff  module  is  restricted  to  requesting  information  or  data 
within  its  own  purview.  The  response  from  the  BOG  will  be  an  appro¬ 
priately  updated  Class  4  event  (see  Design  Note  F).  The  CG  is  allowed 
to  query  any  subordinate  unit  represented  within  the  BOG  for  any  of  the 
periodic  Class  4  events.  For  our  purposes,  those  periodic  Class  4 
events  which  emanate  from  the  special  staff  are  considered  to  be 
coming  from  subordinate  units.  Queries  from  populated  modules  per¬ 
taining  to  planning  documents  "prepared  by"  special  staff  officers 
will  be  responded  to  by  the  controller.  These  planning  documents  will 
be  stored  in  record  and  distributed  as  required. 

Queries  transmitted  from  any  staff  module  will  be  reviewed 
and  edited  at  event  time  for  technical  accuracy.  If  an  error  is 
detected,  the  query  will  not  be  transmitted,  i.e.,  entered  into  the 
simulation. 

Request  for  information  not  within  a  staff  element's  purview 
are  submitted  to  the  responsible  staff  module.  Appropriate  Class  2 
responses  are  discussed  in  Design  Note  G. 

E.3  CLASS  3  EVENTS  TO  CORPS  AND  ADJACENT  DIVISIONS 

The  remaining  Class  3  events,  or  outputs  by  the  division  staff, 
are  directed  to  corps  and/or  adjacent  divisions. 

E.3.1  Periodic  Reports 

The  first  type  of  Class  3  event  within  this  set  are  those 
events  that  represent  periodic  reports  to  headquarters,  e.g.,  DIV 
INTSUM  and  DIV  SITREP.  These  reports  will  only  be  prepared  by  pop¬ 
ulated  modules  since  they  only  reflect  historical  aspects  of  the 
"battle"  and  will  not  affect  the  outcome  of  the  battle.  The  Opera¬ 
tion  Plan,  as  developed  by  a  populated  G3  module,  is  included  in  this 
type  even  though  it  is  not  an  historical  document.  This  concept  of 
having  only  populated  modules  produce  these  documents  is  consonance 
with  our  original  design  concept.  However,  players  within  the  pop¬ 
ulated  modules  may  use  similar  reports  from  units  represented  within 
the  BOG  as  the  basis  for  their  reports.  No  res'ponse  is  expected  or 
required  from  the  controller.  The  reports  will  be  filed  in  record 
and  only  used  to  assist  in  the  measurement  of  populated  staff  per¬ 
formance. 

E.3.2  Requests 

The  second  type  within  this  set  covers  requests  for  the  use 
of  resources  external  to  the  division.  With  the  exception  of  the 
Personnel  Requisition  and  the  Immediate  Request  for  Logistical  Sup¬ 
port  the  responses  to  these  requests  may  be  able  to  affect  the  out¬ 
come  of  the  battle  ongoing  within  the  simulation.  Accordingly, 
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requests  for  additional  resources  will  be  sent  to  corps  or  adjacent 
divisions  by  populated  and  simulated  modules,  as  appropriate,  with 
the  exception  of  the  two  events  mentioned  above.  These  two  requests 
will  only  be  forwarded  by  populated  modules  since  responses  to  these 
requests  will  not  have  an  immediate  affect  on  the  battle  outcome  as 
previously  mentioned.  Requests  will  be  in  the  form  of  frag  orders 
requesting  concurrence  or  non-concurrence  by  the  senior  or  adjacent 
commander.  As  before,  requests  may  only  be  forwarded  by  the  staff 
module  which  exercises  staff  cognizance.  The  only  exception  to  this 
design  consideration  is  the  Nuclear  Release  Request.  The  relative 
importance  of  this  request  dictates  that  it  only  be  released  by  the 
Command  Group  module. 

It  is  incumbent  upon  the  controller  to  respond  to  these  re¬ 
quests  in  a  timely  and  realistic  manner  if  he  is  to  avoid  unduly 
biasing  the  results  of  the  battle  or  the  populated  staff  performance. 

E.3.3  NBC  Reports 

The  next  event  considered  to  be  within  this  set  is  the  NBC 
Report  as  disseminated  by  the  G2  module.  This  report  reflects  on¬ 
going  events  within  the  simulation  and  is  forwarded  to  corps  and 
adjacent  division  commanders  for  their  information.  No  response  by 
the  controller  is  required. 

E.3.4  Queries 

The  fourth  and  final  type  of  Class  3  event  within  this  set 
are  queries  by  populated  modules  to  corps.  These  information  ex¬ 
changes  are  free  text  and  will  arise  when  players  within  populated 
modules  do  not  fully  understand  a  frag  order  as  issued  by  corps. 
Responses  to  queries  of  this  type  must  be  provided  by  the  controller. 

E.4  DISCUSSION  OF  APPENDIX  E.l 

All  Class  3  events  are  identified  in  Appendix  E-l.  The  identi- 
cation  of  a  Class  3  event  includes  the  event  number,  the  tactical 
information  message  included  in  the  event,  the  preparing  module,  the 
module  version  (populated/simulated  or  populated)  capable  of  preparing 
the  message,  the  receiving  module  and  any  information  copies  required 
to  be  sent.  The  event  number  consists  of  the  one  digit  event  class 
plus  the  two  digit  reference  number  associated  with  each  tactical 
information  message  listed  in  Design  Note  A.  Specific  formats  for  each 
of  these  Class  3  events  are  contained  in  Design  Note  D  where  they  are 
listed  by  reference  number.  The  Class  2  event  number  listed  for  some 
of  the  events  in  Appendix  E-l  indicates  that  particular  event  is  also 
distributed  to  one  or  more  principal  staff  modules  for  information 
purposes. 
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Appendix  E-l 
DEFINED  CLASS  3  EVENTS 


EVENT 

NO 

EVENT 

FROM 

MODULE 

VERSION 

TO 

INFO 

301 

QUERY 

CMD 

POP/SIM 

BOG 

— , 

302  (202) 

NUC  REL  REQ 

CMD 

POP/SIM 

CORPS 

- 

310 

QUERY 

FSE 

POP/SIM 

BOG 

- 

31  ID 

QUERY 

FSE 

POP 

CORPS 

- 

312  (212) 

FRAG  ORDER  (FS) 

FSE 

POP/SIM 

BOG 

CORPS/ADJ  DIV 

313  (213) 

DIR  FIRE  SPT 

FSE 

POP/SIM 

CORPS 

ADJ  DIV 

314  (214) 

DPR  FIRE  SPT 

FSE 

POP/SIM 

CORPS 

- 

330 

QUERY 

G2 

POP/SIM 

BOG 

- 

331 D 

QUERY 

G2 

POP 

CORPS 

- 

332  (232) 

FRAG  ORDER  (I) 

G2 

POP/SIM 

BOG 

CORPS/ADJ  DIV 

333D  (233D) 

DIV  INTSUM 

G2 

POP 

CORPS 

- 

334  (234) 

NBC  REPORT 

G2 

POP/SIM 

CORPS 

ADJ  DIV 

350 

QUERY 

G3 

POP/ SIM 

BOG 

351 D 

QUERY 

G3 

POP 

CORPS 

- 

352  (252) 

FRAG  ORDER  (OPS) 

G3 

POP/SIM 

BOG 

CORPS/ADJ  DIV 

353D  (253D) 

DIV  SITREP 

G3 

POP 

CORPS 

- 

354  (254) 

NUC  WARNING  ORDER 

G3 

POP/SIM 

BOG 

CORPS/ADJ  DIV 

355  (255) 

AD  WARNING 

G3 

POP/SIM 

BOG 

CORPS/ADJ  DIV 

356 

REQ  FOR  RESERVES 

G3 

POP/SIM 

CORPS 

- 

357D  (257D) 

OP  PLAN 

G3 

POP 

CORPS 

- 

380 

OUERY 

G1/G4 

POP/SIM 

BOG 

• 

381 D 

QUERY 

G1/G4 

POP 

CORPS 

- 

382  (282) 

FRAG  ORDER  (CSS) 

G1/G4 

POP/SIM 

BOG 

CORPS/ADJ  DIV 

383D  (283D) 

DIV  PDS 

G1/G4 

POP 

CORPS 

- 

384D  (284D) 

PER  LOG  RPT 

G1/G4 

POP 

CORPS 

- 

385D  (285D) 

PERS  REQ 

G1/G4 

POP 

CORPS 

- 

386D 

IR  LOG  SPT 

G1/G4 

POP 

CORPS 

- 
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DESIGN  NOTE  F 


CLASS  4  EVENTS 


F.  1  GENERAL 

Class  4  events  represent  tactical  information  messages  to  in¬ 
dividual  staff  elements  from  subordinate  units  represented  within  the 
BOG  or  higher  and  adjacent  headquarters.  These  Class  4  interface 
events  represent  tasking  from  corps;  response,  tactical  information 
of  an  immediate  utility  of  historical  nature,  immediate  or  preplanned 
requests  from  adjacent  units  or  units  simulated  in  the  BOG.  For  de¬ 
sign  purposes  these  messages  may  be  classified  by  source,  i.e., 
whether  they  emanate  from  the  BOG  or  higher  and  adjacent  headquarters , 
and  by  the  method  with  which  they  are  initiated  or  triggered.  The 
defined  Class  4  events  are  contained  in  Appendix  F-l  and  correspond 
to  the  table  of  Class  4  events  given  in  subsection  4.1.2.  Specific 
design  considerations  for  the  Class  4  events  are  discussed  below. 

F. 2  CLASS  4  EVENTS  GENERATED  BY  THE  BOG 

Class  4  events  stemming  from  the  BOG  are  the  basic  vehicles 
by  which  the  command  and  staff  modules  acquire  and  maintain  their 
perceived  data  bases  concerning  the  division-level  combat.  These 
events  may  be  initiated  or  triggered  in  one  of  four  ways  as  discussed 
below. 

F.2.1  Queries 

The  first  type  of  Class  4  events  generated  by  the  BOG  are 
"queries"  on  the  technical  accuracy  of  frag  orders  or  warning  orders 
issued  by  populated  principal  staff  modules  (i.e.,  the  G2,  G3,  Gl/ 

G4  and  the  FSE).  A  Class  4  query  is  triggered  by  any  technical  error 
in  a  frag  or  warning  order  issued  by  a  populated  staff  module.  The 
query  will  be  as  indicated  in  Design  Note  E  and  will  be  addressed  to 
the  issuing  module. 

F.2.2  Immediate  Battle  Events 


The  second  type  of  Class  4  events  are  triggered  by  the  occur¬ 
rence  of  battle  (Class  5)  events  within  the  BOG.  These  events  repre¬ 
sent  tactical  information  of  an  immediate  nature  or  an  immediate  re¬ 
quest  for  support  and  are  addressed  to  the  principal  staff  module 
having  overall  cognizance  as  indicated  in  Appendix  F-l.  For  example, 
simulated  subordinate  units  within  the  BOG  may  transmit  a  spot  report 
to  the  G2  as  a  result  an  intelligence  collecting  activity  or  they 
may  transmit  a  request  for  support  to  the  G4  when  the  requirement 
arises  as  a  result  of  the  combat  activity  represented  within  the  BOG. 
These  type  messages  are  one  time  transmittals  and  the  information  con- 
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tained  within  the  messages  will  not  be  retained  or  stored  as  such  in 
the  real  data  base.  Accordingly,  the  staff  modules  (and  the  command 
group)  will  not  be  allowed  to  query  the  simulated  units  within  the 
BOG  directly  on  these  event- triggered  messages  to  obtain  more  accurate 
or  additional  information. 

F.2.3  Periodic  Battle  Events 


Tactical  messages  representing  tactical  reports  or  preplanned 
requests  for  support  which  are  submitted  to  a  cognizant  staff  module 
on  a  periodic  basis  cover  the  third  type  of  Class  4  event  generated 
by  the  BOG.  They  are  primarily  periodic  summary  reporting  events  of 
tactical  information  or  preplanned  requests  for  additional  fire  or 
logistical  support,  and  as  such,  will  normally  be  triggered  by  the 
BOG  clock  at  the  appropriate  time. 

These  time  triggered  events  may  also  be  triggered  in  response 
to  a  query  from  the  appropriate  staff  module  or  the  command  group 
under  one  of  the  following  conditions:  the  message  was  degraded 
during  transmission;  the  message  did  not  arrive  on  time;  or  a  timely 
update  is  required.  These  queries  may  be  transmitted  by  a  populated 
or  simulated  staff  module.  Responses  to  queries  from  the  staff  or 
command  modules  will  be  appropriately  updated  Class  4  events.  Reponses 
to  staff  module  will  only  be  addressed  to  the  requesting  staff  module. 

A  response  to  the  command  module  will  be  addressed  to  the  command 
module  with  an  information  copy  to  the  cognizant  staff  module. 

Event  492,  the  CAPE  reports,  may  be  event  or  time  triggered. 
These  reports  represent  a  "quick  assessment"  of  a  unit's  personnel 
and  logistics  status.  The  reports  may  be  forwarded  by  subordinate 
units  immediately  after  an  engagement  or  they  may  be  forwarded 
periodically.  The  CAPE  reports  may  also  be  triggered  in  response  to 
a  query  from  a  populated  G1/G4  module  or  command  module. 

F. 3  CLASS  4  EVENTS  GENERATED  BY  OTHER  THAN  THE  BOG 

The  first  group  of  Class  4  events  within  this  set  that  will  be 
considered  are  tnose  tactical  information  messages  which  emanate  from 
record.  The  record  concept  is  a  repository  used  by  the  controller  to 
store  those  tactical  documents  which  are  not  directly  entered  into  or 
generated  or  received  by  the  division  staff,  as  discussed  in  Design 
Note  G,  are  another  example  of  the  tyoe  of  tactical  documents  stored 
in  record.  Selected  tactical  information  messages  from  corps  and 
special  staff  officers  will  be  retained  in  records  and  entered  into 
the  play  of  the  game  at  appropriate  times  by  the  controller.  These 
events  must  be  prepared  in  advance  of  the  play  of  the  game  in  accord¬ 
ance  with  the  desired  scenario,  objectives  of  the  investiaator ,  and 
the  design  of  the  experiment. 


F-2 


It  is  readily  apparent  that  this  group  of  inputs  to  the  di¬ 
vision  staff  define  the  basis  for  the  scenario  to  be  played  and  is 
the  result  of  the  experimental  design  established  in  accordance  with 
the  objectives  of  the  investigator.  These  same  Class  4  events  will 
be  used  by  the  controller  in  his  pre-processing  efforts  to  build  the 
SCENARIO  File  on  magnetic  tape.  Accordingly,  attention  to  detail  in 
the  preparation  of  these  tactical  documents  will  pay  dividends  in  the 
pre-processing  efforts  to  establish  the  SCENARIO  Files.  The  record 
concept,  as  defined  above,  and  the  SCENARIO  File  comprise  the  basic 
tools  which  provide  this  simulation  with  the  flexibility  to  allow 
adaptation  to  various  scenario  situations  and  major  forms  of  ma¬ 
neuver. 

F . 3 . 1  General  Si tuations 

All  inputs  from  corps  of  this  type  are  grouped  into  one  event 
defined  as  the  General  Situation.  The  General  Situation  will  be  given 
to  all  populated  staff  modules  prior  to  the  commencement  of  the  game 
at  a  time  determined  by  the  investigator.  After  analysis  of  the  Gen¬ 
eral  Situation,  players  may  query  the  investigator/controller  for 
clarification  or  amplification.  The  General  Situation  will  include 
the  following  information: 

•  Corps  objectives 

•  Adjacent  division's  mission  and  dispositions 

•  Analysis  of  area  of  operations 

•  Enemy  order  of  battle  handbook 

•  Current  periodic  intelligence  report 
F.3.2  Special  Situation 

The  second  Class  4  event  contained  in  record  defines  the 
Special  Situation.  This  event  must  also  be  prepared  in  advance  of 
the  play  of  the  game  and  represents  a  detailed  brief  of  the  tactical 
situation  to  the  division  staff  officers  coming  on  duty.  The  Special 
Situation  is  provided  to  players  within  populated  modules  prior  to 
the  commencement  of  the  game  and  after  the  players  have  completed 
their  analysis  of  the  General  Situation.  Players  may  query  the  in¬ 
vestigator/controller  for  clarification  or  amplification.  In  addi¬ 
tion,  players  may  reassign  missions  and  units  within  their  purview. 

The  Special  Situation  is  actually  the  division's  perception  of  its 
own  and  the  opposing  forces  and  will,  accordingly,  include  the  follow¬ 
ing  information: 
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Division's  mission 


• 

•  Task  organization 

•  Subordinate  unit  identification,  unit  type,  and  unit 
mission 

•  Subordinate  unit  disposition,  location  and  combat  ef¬ 
fectiveness 

•  Subordinate  units'  personnel  and  logistic  status, 

•  Opposing  force  disposition,  location  and  combat  effec¬ 
tiveness. 

F.3.3  Special  Staff  Officers 

The  next  set  of  events  contained  in  record  are  related  to 
special  staff  officers.  Special  staff  officers  are  responsible  for 
developing  certain  estimates  and  annexes  during  the  preparation  of 
an  operations  order.  When  the  objectives  of  the  investigator  in¬ 
clude  an  evaluation  of  the  planning  functions  as  performed  by  certain 
populated  modules  these  estimates  and/or  annexes  must  be  prepared  in 
advance.  These  tactical  documents  are  stored  in  record  and  made 
available  by  the  controller  to  appropriate  populated  staff  modules 
in  accordance  with  the  play  of  the  game.  These  Class  4  events  which 
represent  the  planning  output  of  special  staff  officers  are  as  follows 

•  Fire  Support  Element  Special  Estimate/Annex 

•  Operations  Special  Estimate/ Annex 

•  DISCOM  Situation  Report 

0  CMO  Estimate/Annex 

F . 3 . 4  Corps  Orders  and  Reports 

The  last  set  of  events  contained  in  this  group  are  those  Class 
4  events  which  represent  on-going  actions  from  higher  and  adjacent 
headquarters.  These  represent  tactical  information  messages  to  the 
division  staff  front  corps  or  adjacent  divisions  in  accordance  with 
the  objectives  of  the  investigation  and  are  used  to  control  the  play 
of  the  game.  These  events  are  normally  prepared  in  advance  to  satisfy 
specific  investigative  objectives,  stored  in  record,  and  distributed 
to  populated  staff  modules  by  the  controller  in  accordance  with  a 
pre-established  time  schedule.  However,  the  investigator  will  have 
the  flexibility  to  generate  these  events  after  the  exercise  has 
started  if  he  ascertains  a  need  to  influence  the  play  of  the  game. 
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This  set  of  events  include  the  following  tactical  information  trans¬ 
fers  : 

•  Corps  frag  order  (FSE) 

•  Corps  frag  order  { Intel  1) 

•  Corps  frag  order  (Ops) 

•  Corps  frag  order  (CSS) 

•  Corps  combat  intelligence  report 

•  Corps  NBC  report 

•  Adjacent  division  requests  * 

** 

•  Response 

As  described  above,  this  group  of  Class  4  events  that  emanate 
from  record  are  only  directed  toselected  populated  modules  as  required 
by  the  objectives  of  the  investigation.  This  group  of  tactical  in¬ 
formation  transfers  is  not  required  to  be  assimilated  by  the  computer 
program.  The  messages  are  designed  to  provide  additional  realism  to 
the  simulation  and  to  provide  the  investigator/controller  with  a  ve¬ 
hicle  to  directly  influence  the  play  of  the  game.  Players  within 
populated  modules  will  be  allowed  to  query  corps,  adjacent  divisions 
and  special  staff  officers  on  any  of  these  events  in  record.  Queries 
and  responses  are  free  text  formats  since  none  of  the  information  will 
be  directly  entered  into  the  computer.  However,  all  tactical  docu¬ 
ments  which  enter  and  leave  record  will  be  processed  by  the  controller 
and  input/output  times  posted  within  the  computer  simulation  for  later 
analysis. 


*  Requests  from  adjacent  divisions  are  "interrogatory"  frag  order 
which  define  the  task  or  support  requests  from  that  division. 

**  Responses  are  not  prepared  in  advance.  Responses  represent  corp, 
adjacent  division  and  special  staff  answers  to  free  text  queries 
on  any  of  these  messages. 
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F.4  SPECIAL  CONSIDERATION 
F.4.1  CEWI  Bn 


Special  note  must  be  made  of  those  Class  4  events  (i.e.,  tactical 
information  messages)  directed  to  the  G2  and  G3  staff  modules  which 
originate  from  organic  division  intelligence  units.  The  Combat  Elec¬ 
tronic  Warfare  Intelligence  (CEWI)  Battalion  is  subordinate  to  the 
division  and  is  responsible  for  providing  combat  intelligence  and 
electronic  warfare  functions  in  support  of  the  division.  It  is  recog¬ 
nized  that  the  organization  and  employment  of  the  CEWI  Bn  is  presently 
undergoing  revision  within  the  U.S.  Army.  However,  since  we  are 
primarily  interested  in  the  information  exchanges  between  the  division 
staff  and  the  CEWI  Bn  it  is  sufficient  to  model  the  CEWI  Bn  implicitly. 
This  will  be  done  via  a  routine  titled  the  All  Source  Analysis  Center 
(ASAC),  a  term  which  is  in  current  usage  for  the  post-1985  CEWI  Bn. 

The  ASAC  routine  within  this  simulation  will  model  the  EWIOC,  TCAC, 
and  BICC  of  the  CEWI  Bn  and  provide  for  the  evaluation  of  intelligence 
and  electronic  warfare  tasks  within  the  BOG  and  for  integrated  intel¬ 
ligence  analysis,  dissemination  and  reporting  from  intelligence  and 
EW  resources  within  the  BOG.  The  ASAC  will  collect  and  evaluate  raw 
information  from  all  sources  and  forward  the  following  information  to 
G2/G3.  Appendix  F-l  indicates  how  each  exchange  is  initiated  and  the 
receiving  module: 

•  Weather  forecast 

•  Combat  intelligence  report 

•  Aggregated  target  list  (intelligence) 

0  Enemy  electronic  order  of  battle 

0  Estimate  of  enemy  strength/disposition 

F.4. 2  Special  Staff 

Special  consideration  is  also  given  tQ  those  Class  4  events 
which  represent  the  input  to  the  division  staff  from  the  special  staff 
officers  with  regard  to  the  status  of  non-maneuver  units.  The  status 
of  these  special  purpose  units  will  be  maintained  within  the  BOG  and 
reported  periodically  to  the  cognizance  staff  module  or  in  response 
to  a  query  from  the  appropriate  staff  module. 

•  Aviation  sortie  status 

•  FSE  support  status 

0  Nuclear  weapons  status 

•  TACP  status 

•  Air  defense  artillery  status 
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Several  of  the  Class  4  events  from  the  BOG  are  tactical  re¬ 
ports  or  requests  which  will  have  multiple  formats.  These  particular 
Class  4  events  represent  events  which  can  be  grouped  under  a  single 
generic  title.  Events  423  and  424,  requests  for  additional  fire  sup¬ 
port,  represent  immediate  and  preplanned  requests  for  field  artillery, 
naval  gunfire  and  close  air  support.  Event  426  represents  the  status 
of  air  defense  artillery,  tactical  air  sorties,  and  NBC  weapons. 

Event  443  represents  the  various  spot  reports  issued  by  all  intel¬ 
ligence  collecting  activities  whether  by  a  maneuver  unit  or  an  ASAC 
asset.  The  five  standard  NBC  reports  are  represented  by  event  434. 
Event  460  represents  unit  progress  reports  for  units  in  contact  or 
not  in  contact.  Casualty,  ammunition,  POL  and  equipment  status  reports 
are  represented  by  event  492,  the  CAPE  reports.  Events  486  and  493 
represent  immediate  and  preplanned  requests  for  logistical  support 
including  troop  lifts  and  medical  evacuations.  All  other  Class  4 
events  will  utilize  single  formats  for  the  tactical  information 
messages . 


F. 5  DISCUSSION  OF  APPENDIX  F-l 

All  Class  4  events  are  identified  in  Appendix  F-l.  The  identi¬ 
fication  of  a  Class  4  event  includes  the  event  number,  the  tactical  in¬ 
formation  message  included  in  the  event,  the  receiving  modules,  the 
source  of  the  event,  and  the  method  by  which  the  event  is  triggered. 

The  event  number  consists  of  the  one  digit  event  class  plus  the  two 
digit  reference  numbers  associated  with  each  tactical  information 
messaae  listed  in  Design  Note  A.  Specific  formats  for  each  of  these 
Class  4  events  are  contained  in  Design  Note  D  where  they  are  listed 
by  reference  number. 
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Appendix  F-l 
CLmSS  4  EVENTS 


EVENT 


NO. 

EVENTS 

TO 

FROM 

TRIGGER 

415 

ARTY  SITREP 

FSE 

BOG 

TIME/QUERY 

416 

TGT  LIST  (ARTY) 

FSE 

BOG 

TIME/QUERY 

417 

FU  FIRE  SPT  CAP 

FSE 

BOG 

TIME/OUERY 

418 

EU  FIRE  SPT  CAP 

FSE 

BOG 

TIME/QUERY 

423 

IR  FIRE  SPT 

FSE 

BOG 

EVENT 

423D 

IR  FIRE  SPT 

FSE 

RECORD 

EVENT 

424 

PR  FIRE  SPT 

FSE 

BOG 

TIME/OUERY 

425 

TGT  (I) 

FSE 

BOG 

EVENT 

426 

FSE  SPT  STATUS 

FSE 

BOG 

TIME/OUERY 

427 

QUERY  (FS) 

FSE 

BOG 

ERROR 

428D 

FSE  EST/ANNEX 

FSE 

RECORD 

EVENT 

429D 

FRAG  ORDER  (FS) 

FSE 

RECORD 

EVENT 

434 

NBC  REPORT 

G2 

BOG 

EVENT 

434D 

NBC  REPORT 

G2 

RECORD 

EVENT 

435 

WX  FORECAST 

G2 

BOG 

TIME/ OUEPY 

441 

BDE  INTSUM 

G2 

BOG 

TIME/OUERY 

442 

SHELL  REPORT 

G2 

BOG 

EVENT 

443 

SPOT  REPORT 

G2 

BOG 

EVENT 

444 

CBT  INTEL  RPT 

G2 

BOG 

EVENT 

444D 

CBT  INTEL  RPT 

G2 

RECORD 

EVENT 

445 

POST  STRIKE  DAM  RPT 

G2 

BOG 

EVENT 

446 

EST  OF  EN  STRENGTH 

G2 

BOG 

TIME/OUERY 

447 

TGT  LIST  (C) 

G2 

BOG 

TIME/OUERY 

448 

QUERY  (I) 

G2 

BOG 

ERROR 

449D 

FRAG  ORDER  (I) 

G2 

RECORD 

EVENT 

459 

INITIAL  EN  CONT 

G3 

BOG 

EVENT 

460 

UNIT  PROG  RPT 

G3 

BOG 

EVENT 

461 

LOSS  CONT  W/FU 

G3 

BOG 

EVENT 

462 

EOOB 

G3 

BOG 

TIME/QUERY 

465 

BDE/BN  SITREP 

G3 

BOG 

TIME/OUERY 

466 

AD  ALERT 

G3 

BOG 

EVENT 

467 

AVN  SORTIE  STATUS 

G3 

BOG 

TIME/OUERY 

468 

OUERY  (CPS) 

G3 

BOG 

ERROR 

469 

QUERY  (NWO) 

G3 

BOG 

ERROR 

470 

QUERY  (AOW) 

G3 

BOG 

ERROR 

471 D 

FRAG  ORDER  (OPS) 

G3 

RECORD 

EVENT 

472D 

OPS  EST/ANNEX 

G3 

RECORD 

EVENT 

EVENT 


NO. 

EVENTS 

TO 

FROM 

TRIGGER 

486 

IR  LOG  SPT 

G1/G4 

BOG 

EVENT 

491 

BDE/BN  PDS 

G1/G4 

BOG 

TIME/QUERY 

492 

CAPE  REPORT 

G1/G4 

BOG 

TIME/OUERY/EVENT 

493 

PR  LOG  SPT 

G1/G4 

BOG 

TIME/QUERY 

'494 

QUERY  (CSS) 

G1/G4 

BOG 

ERROR 

495D 

FRAG  ORDER  (CSS) 

G1/G4 

RECORD 

EVENT 

496D 

DISCOM  SITREP 

G1/G4 

RECORD 

TIME/QUERY 

497D 

CMO  EST/ANNEX 

G1/G4 

RECORD 

EVENT 

D  GENERAL  SIT 
D  SPECIAL  SIT 


POP  MOD  RECORD 
POP  MOD  RECORD 


EVENT 

EVENT 


DESIGN  NOTE  G 


CLASS  2  EVENTS 


G.l  GENERAL 

The  Class  2  events  represent  the  tactical  information  trans¬ 
fers  between  staff  modules  as  the  result  of  staff  action  or  inter¬ 
action.  These  interface  events  will  trigger  action-handling  (Class 
1)  events  within  individual  simulated  staff  modules  and  undefined 
events  within  populated  modules.  The  defined  Class  2  events  for  both 
populated  and  simulated  modules  are  contained  in  Appendix  G-l .  Design 
Note  D  contains  the  formats  which  are  generated  by  appropriate  staff 
modules  to  transmit  the  tactical  information  contained  within  the  Class 
2  events.  Before  preceding  to  specific  design  considerations,  a  dis¬ 
cussion  of  staff  module  capabilities  and  how  they  interact  will  be 
useful . 

G .  1 . 1  Staff  Module  Capabilities 

The  division  principal  staff  modules  (to  include  the  command 
module)  may  be  populated  or  simulated  in  accordance  with  the  objec¬ 
tives  of  the  ARI  investigator.  It  is  exDected  that  at  least  one  staff 
module  will  be  populated  in  order  to  conduct  any  meaningful  behavioral 
science  research.  The  primary  emphasis  of  most  investigations  will  be 
on  the  performance  of  the  players  in  the  populated  modules.  Accord¬ 
ingly,  the  investigator  may  require  players  within  populated  modules 
to  perform  any  or  all  of  the  functions  normally  required  of  that  par¬ 
ticular  staff  module.  The  functions  for  a  populated  staff  module  in¬ 
clude  planning  for  future  operations,  executing  the  current  operation, 
or  reporting  interim  results  of  the  current  operation.  All  the  func¬ 
tions  required  of  a  populated  staff  module  will  not  be  duplicated 
within  a  simulated  staff  module  for  the  following  reasons. 

Computer  simulations  can  assist  in  the  planning  functions  by 
providing  current  information  on  friendly  and  enemy  forces.  However, 
a  simulation  cannot  plan.  Accordingly,  simulated  staff  modules  will 
not  contain  algorithms  to  perform  planning  functions.  This  limita¬ 
tion  does  not  restrict  certain  outputs  of  simulated  staff  modules 
from  being  used  by  populated  modules  for  planning  purposes. 

Computer  simulations  are  able  to  compile  necessary  informa¬ 
tion  in  order  to  produce  reports  as  evidenced  within  the  ARI  simu¬ 
lation  by  the  outputs  generated  by  the  BOG.  However,  most  reports 
generated  by  a  division  staff  module  are  only  used  for  historical 
purposes  or,  in  the  case  of  populated  staff  modules,  they  may  be  a 
tool  for  measuring  staff  performance.  In  any  event,  these  reports 
only  reflect  what  has  happened  within  the  simulation  and  have  no 
bearing  on  future  events  within  the  simulation.  For  these  reasons, 
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simulated  staff  modules  will  not  contain  alqorithms  for  producinq 
historical  reports  such  as  a  D I V  SITREP  or  DIV  INTSUM. 

In  summary,  populated  staff  modules  will  perform  those  func¬ 
tions  necessary  for  producinq  decision  variables  or  outputs  associated 
with  planning, executing  and/or  reporting  the  battle.  Simulated  staff 
modules  will  only  perform  those  functions  necessary  for  producing 
outputs  associated  with  executing  the  battle. 

G . 1 . 2  Staff  Module  Outputs 

The  functions  of  a  staff  module,  whether  live  or  populated, 
normally  result  in  a  tactical  information  transfer  to  higher  or 
adjacent  headquarters,  subordinate  units,  special  staff  officers  or 
other  principal  staff  modules.  (Implicit  in  the  exchange  between 
principal  staff  modules  is  the  coordination  required  of  the  division 
staff.)  The  tactical  information  transfers  may  be  either  directive, 
informative  or  interrogatory  in  nature  and  are  defined  as  either 
Class  2  or  Class  3  events.  Class  2  events  represent  exchanges  in¬ 
ternal  to  the  division  staff  while  Class  3  events  represent  exchanges 
external  to  the  division  staff.  Class  3  events  were  discussed  in 
Annex  E.  The  outputs  of  the  staff  modules  are  not  exclusively  Class 
2  or  Class  3  events.  A  single  staff  action  may  result  in  a  Class  2 
and  a  Class  3.  For  example,  a  frag  order  produced  by  the  G3  module 
triggers  both  a  Class  3  event  and  a  Class  2  event.  The  frag  order 
transfers  tactical  directives  to  subordinate  units  and  information  to 
higher  and  adjacent  headquarters  (Class  3)  while  transferinq  tactical 
information  for  coordination  purposes  to  principal  staff  modules 
(Class  2).  There  are  Class  2  events,  however,  which  are  only  internal 
to  the  division  staff  and,  similarly,  there  are  Class  3  events  for 
which  information  copies  are  not  provided  to  other  staff  modules. 

G.1.3  Staff  Module  Data  Transfers 


Populated  staff  modules  will  be  provided  standard  forms  for 
recording  information  to  be  transfered  externally  from  the  module 
for  each  of  the  allowable  Class  2  and  Class  3  events  (See  Design  Note 
D).  Players  may  use  the  forms  to  initiate  .action,  respond  to  requests 
or  any  other  action  necessary  to  affect  interaction  with  other  staff 
modules  or  the  simulation.  All  outputs  of  populated  modules  will  en¬ 
ter  the  simulation  via  the  controller  who  will  distribute  the  output 
as  indicated  by  the  players.  Outputs  of  simulated  staff  modules 
will  automatically  be  distributed  among  the  staff  modules  in  accord¬ 
ance  with  the  distribution  of  Appendices  E-l  and  G-l.  One  copy  will 
be  retained  by  the  controller  for  record  purposes.  Specific  design 
considerations  for  Class  2  events  are  discussed  below. 


>  . 
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G .  1 . 4  Staff  Module  Configurati on s 

The  preceding  discussion  clarified  some  of  differences  between 
populated  and  simulated  staff  modules  in  terms  of  their  capabilities 
and  outputs.  These  outputs.  Class  2  events,  will  be  handled  in  a 
different  manner  for  each  of  four  alternative  subconfiguration  arrange¬ 
ments  . 

First  of  all,  if  both  the  sending  and  receiving  staff  modules 
are  simulated  versions,  then  the  tactical  information  transfer  events 
will  be  represented  simply  by  time  delays  commensurate  with  the  normal 
administration  delays  between  the  elements.  Exchanges  will  be  limited 
to  that  tactical  data  which  is  current,  associated  with  the  execution 
of  the  battle,  and  within  the  purview  of  the  transmittino  and  receivina 
staff  modules. 

If,  secondly,  the  message  exchange  event  is  from  a  live  player 
version  to  a  simulated  module,  then  the  event  will  be  executed  just 
like  a  Class  3  event  as  far  as  the  live  players  are  concerned.  That 
is,  hard  copy  will  be  presented  to  the  controller  in  both  cases.  If 
the  event  is  concerned  with  the  execution  of  the  battle,  and  it  af¬ 
fects  the  simulation,  the  controller  will  enter  it  into  the  simulation 
with  appropriate  time  delays.  If  the  event  concerns  plannina  or  his¬ 
torical  reports  or  it  does  not  affect  the  simulation  the  controller 
will  enter  it  into  the  record. 

If,  thirdly,  the  message  exchange  event  is  an  input  from  a 
simulated  module  to  a  livtt  player  version,  then  the  event  will  appear 
to  be  a  Class  4  event  to  the  live  players.  The  message  will  come 
directly  from  the  simulation  if  it  relates  to  the  ongoing  battle. 

If  it  is  a  required  input  for  planning  purposes  it  will  come  from 
record  via  the  controller. 

Finally,  if  the  message  exchange  events  occur  in  a  configura¬ 
tion  in  which  both  staff  modules  are  live  player  versions,  the  Class  2 
events  will  not  interact  with  the  simulation.  However,  the  event 
transactions  will  be  recorded  by  the  controller  and  will  appear  as 
a  TTY  printout  to  the  receiving  module.  These  Class  2  events  between 
populated  modules  are  only  minimally  constrained  in  that  the  exchange 
must  be  within  the  objectives  of  the  investigation  and  they  must  be 
hardcopy,  i.e.,  oral  exchanges  are  not  permitted. 

G.2.  CLASS  2  EVENTS 

Class  2  events  may  be  grouped  into  the  following  four 
separate  categories. 


G.2.1  Information  Events 


The  first  group  contains  those  Class  2  events  which  are  pre¬ 
cipitated  by  a  staff  module  as  a  result  of  and  concurrently  with  Class 
3  events.  These  Class  2  events  represent  information  copies  to  principal 
staff  modules  as  the  result  of  a  tactical  information  transfer  external 
to  the  division  staff.  If  the  initiating  staff  module  is  simulated, 
the  internal  distribution  (Class  2  event)  will  be  as  indicated  in 
Appendix  G-l  while  the  external  distribution  (Class  3  event)  will  be 
as  shown  in  Appendix  E-l .  If  the  releasing  module  is  populated  both 
internal  and  external  distribution  will  be  as  indicated  by  the  players 
of  that  particular  staff  module.  The  Class  2  events  which  are  precipi¬ 
tated  as  a  result  of  a  Class  3  event  are  as  follows: 

•  Nuclear  Release  request 

•  Frag  Order  (Fire  Support) 

•  Division  Immediate  Request  for  Fire  Support 

•  Division  Preplanned  Request  for  Fire  Support 

•  Frag  Order  (Intelligence) 

•  Division  INTSUH* 

•  NBC  Report 

•  Frag  Order  (Operations) 

•  Division  SITREP* 

•  Nuclear  Warning  Order 

•  Air  Defense  Warning 

•  Operation  Plan* 

•  Frag  Order  (Combat  Service  Support) 

•  Division  Personnel  Daily  Summary* 

•  Periodic  Logistic  Report* 

t  Personnel  Requisition* 

In  the  event  the  G3  module  is  populated  and  required  to  produce  a  SITREP, 
the  Arty  SITREP  and  Intelligence  paragraph  of  the  SITREP  can  be  re¬ 
quested  as  inputs  from  the  FSE  and  G2  modules,  respectively.  This  is 
true  whether  these  modules  are  populated  or  simulated.  When  the  G3 
module  is  not  populated,  there  is  no  requirement  for  the  Arty  SITREP 
or  the  Intelligence  paragraph  of  the  SITREP  to  be  output  by  simulated 
modules  since  these  outputs  are  historical  in  nature  and,  as  such,  do 
not  affect  the  ongoing  simulation. 


*0utput  by  populated  staff  modules  only. 
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G.2.2  Planning  Events 


The  second  major  grouping  of  Class  2  events  includes  those 
events  which  precipitate  planning,  reflect  the  results  of  ongoing  olan- 
ning  or  are  the  final  product  of  plannina.  As  stated  previously,  these 
outputs  related  to  planning  will  only  be  produced  by  populated  staff 
modules.  Under  certain  circumstances  a  populated  staff  module  may 
require  inputs  of  this  nature  from  a  simulated  staff  module.  If  this 
is  the  case,  the  input  would  be  provided  in  a  timely  manner  by  record 
(via  the  controller).  This  input  would  appear  to  be  the  populated 
staff  modules  as  if  it  came  from  another  populated  module.  For  example, 
if  one  of  the  objectives  of  the  investigation  was  to  have  the  populated 
G3  module  produce  an  Operation  Plan,  the  G3  would  need,  inter  alia,  a 
Fire  Support  Annex.  When  the  FSE  module  is  also  populated,  the  players 
within  the  FSE  module  will  nrepare  the  Fire  Support  Annex.  If  the  FSE 
module  were  being  simulated,  it  would  be  necessary  to  prepare  the  Fire 
Support  Annex  in  advance  of  the  play  and  have  the  controller  input  it 
to  the  populated  G3  at  the  appropriate  time.  The  following  Class  2 
events  are  directly  related  to  planning  and  will  only  be  output  by  a 
populated  module.  To  reiterate,  if  it  is  known  that  a  planning  output 
is  required  from  a  simulated  module  by  a  populated  module  during  the 
play  of  the  game,  the  output  must  be  prepared  in  advance  and  placed  in 
record. 

•  Mission  Analysis 

•  Commander's  Guidance 

•  Fire  Support  Annex 

t  Intelligence  Estimate 

•  Intelligence  Annex 

•  Operations  Estimate 

A  Operations  Plan 

•  Combat  Service  Support  Estimate 

•  Combat  Service  Support  Annex. 

3.2.3  Tactical  Information  Events 


The  third  major  grouping  of  Class  2  events  categorize  those 
transfers  of  information  among  staff  which  occur  more  or  less  on  a 
routine  basis.  These  events  transfer  tactical  information  from  a 
staff  module  having  staff  cognizance  to  specific  staff  modules  which 
require  the  information  routinely  as  an  aid  in  making  timely  decisions. 
This  grouping  of  events  has  no  standard  Class  3  counterpart.  However, 
it  is  conceivable  that  higher  and  adjacent  commands  may  query  the  divi¬ 
sion  commander  on  this  category  of  Class  2  events.  Simulated  Staff 
modules  will  transfer  this  information  to  the  staff  modules  indicated 
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in  Appendix  G-l,  whether  populated  or  simulated,  on  a  periodic  basis. 
Updates  will  be  provided  when  significant  changes  occur.  Populated 
staff  modules  will  transfer  the  information,  via  the  controller,  as 
determined  by  the  players  internal  procedures.  The  third  aroup  includes 
the  following  Class  2  events: 

•  Target  List  (Artillery) 

•  Friendly  Unit  Fire  Support  Capabilities 

•  Enemy  Unit  Fire  Support  Capabilities 

0  Weather  Forecast 

•  Electronic  Order  of  Battle. 

G.2.4  Staff  Coordination  Events 


The  final  major  grouping  of  Class  2  events  contains  the  fol¬ 
lowing  exchanges  among  staff  modules  (including  the  command  module): 

•  Request 

0  Staff  query 

#  Retransmit  message 

0  Response. 

This  group  of  Class  2  events  represent  what  in  the  real  world  is  an 
unstructured  exchange  of  information  that  occurs  internal  to  the  divi¬ 
sion  staff  in  order  to  coordinate  planning,  execution,  and  reporting 
of  the  battle.  Since  such  exchanges  in  the  simulation  involve  simulated 
modules,  they  must  be  structured  and  formatted  for  simulation  purposes. 
Table  G-l  indicates  the  various  Class  2  responses  to  staff  queries, 
requests,  decisions,  and  retransmitted  messages.  Design  considerations 
for  each  of  these  exchanges  are  postulated  below. 

Class  2  Request  Events  are  requests  by  a  particular  staff 
module  directed  to  the  command  module  or  another  staff  module.  These 
requests  are  limited  to  requests  for  release  of  frag  orders  and  repre¬ 
sent  the  staff  coordination  that  must  occur  internal  to  the  division 
staff  prior  to  the  release  of  a  message  that  is  directive  in  nature. 
Requests  will  be  in  the  form  of  a  completed  frag  order  (a  Class  3  event) 
with  an  indicator  for  requesting  release  approval.  Class  2  Requests 
may  occur  in  one  of  the  following  three  ways: 

(1)  Staff  modules  will  forward  requests  to  the  command  module 
when  the  content  of  the  frag  order  has  broached  a  certain  threshold  as 
established  by  the  commander's  guidance  and/or  the  limits  of  delegated 
authori ty. 
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(2)  Staff  modules  will  forward  requests  to  another  staff 
module  requesting  concurrence  on  the  release  of  a  specific  frag  order 
when  the  release  of  that  frag  order  contains  information  within  the 
purview  of  the  other  staff  module. 

(3)  Populated  staff  modules  may  ascertain  the  necessity  for 
the  release  of  a  frag  order  not  within  their  purview.  In  this  event 
the  populated  staff  module  will  forward  a  request  to  a  staff  module 
having  staff  cognizance  recommending  that  it  be  released. 

Within  a  simulated  staff  module,  algorithms  for  Class  1 
events  must  allow  for  requests  to  be  staffed  as  outlined  above.  Pop¬ 
ulated  staff  modules  will  establish  internal  procedures  for  releasing 
or  requesting  the  release  of  frag  orders.  It  should  be  noted  that 
the  response  by  a  command  module  to  a  request  from  a  staff  module 
will  be  the  commander's  decision  as  described  below  in  paragraph  G.2.5. 
Responses  to  the  second  type  request  will  be  the  return  of  the  completed 
frag  order  indicating  concurrence  or  non-concurrence  by  the  reviewinq 
staff  module.  The  response  to  the  third  type  request  will  be  a  copy 
of  the  issued  frag  order  or  its  return  with  non-concurrence. 

Staff  queries  are  the  second  category  of  Class  2  events 
within  this  grouping.  Staff  queries  simulate  the  continuous  and  in¬ 
formal  coordination  that  occurs  between  and  amona  the  division  staff. 
Essentially,  these  staff  queries  are  requests  for  additional  or  up¬ 
dated  information  and,  as  such,  will  only  be  directed  to  staff  modules 
having  cognizance  over  the  type  of  information  desired.  Simulated 
staff  modules  are  restricted  to  formulating  staff  queries  on  the  exe¬ 
cution  of  the  battle  only  and  the  queries  will  be  transmitted  directly 
to  the  cognizant  staff  module  whether  populated  or  simulated.  Staff 
queries  in  the  simulated  modules  will  be  prompted  by  insufficient  or 
obsolete  data  required  to  compile  an  output  by  that  staff  module. 

This  required  output  may  be  a  Class  2  or  a  Class  3  event.  Populated 
staff  modules  have  a  greater  latitude  in  formulating  queries  in  that 
they  may  initiate  queries  concerning  planning,  executina  and  report¬ 
ing  at  the  players  discretion.  All  staff  queries  originatina  from 
populated  staff  modules  will  be  routed  through  the  controller  as  are 
all  other  outputs  of  populated  modules.  The  controller  will  "release" 
the  staff  query  to  the  staff  module(s)  as  indicated  and  will  provide 
the  response,  when  available,  from  populated  staff  modules  or  record. 
Responses  from  simulated  staff  modules  will  be  transmitted  directly 
from  the  simulation.  Each  staff  module  will  maintain  current  status 
of  information  within  its  purview.  It  is  this  information  that  is 
subject  to  queries  from  other  staff  modules.  The  maintenance  of  in¬ 
formation  is  at  the  discretion  of  the  players  within  populated  modules. 
Within  simulated  modules  the  following  files  will  be  maintained: 


Table  G-l.  Responses  to  Staff  Oueries,  Requests,  Decisions  by  the 
Commander,  and  Retransmitted  Messaoes. 


♦INITIATED  BY  POPULATED  MODULE  ONLY. 


FIRE  SUPPORT  ELEMENT 


•  Target  List  (Artillery) 

•  Friendly  Unit  Fire  Support  Capabilities 

•  Enemy  Unit  Fire  Support  Capabilities 

•  Fire  Support  Element  Support  Status 

G2 

•  Estimates  for  Enemy  Strength/Dispositions 

G3 

•  Friendly  Unit  Locations 

•  Unit  Progress 

•  Aviation  Sortie  Status 

G1/G4 

•  Unit  CAPE  Report 

•  Unit  Personnel  Daily  Summary 

It  should  be  noted  that  these  files  are  in  reality  Class  4  events 
and  represent  current  data  on  the  execution  of  the  battle  as  per¬ 
ceived  by  each  staff  module.  The  staff  module  responsible  for  main¬ 
taining  the  data  receives  it  from  the  simulation  via  Class  4  events. 

(See  Design  Note  F.)  The  data  will  be  maintained  at  the  battalion 
level  of  resolution.  Accordinaly,  staff  modules  will  be  able  to  "query" 
the  complete  "file"  or  one  or  more  specific  organic  battalions. 

This  leads  directly  to  the  next  category  of  events  within 
this  grouping,  the  response.  A  response  is  the  answer  to  a  request 
for  release  of  a  frag  order  or  staff  query  and  as  such,  completes 
the  staff  coordination  cycle.  Response  to  frag  orders  are  as  dis¬ 
cussed  above.  Responses  to  staff  queries  wi>l  be  directed  to  the 
requestor  and  will  be  a  copy  of  the  indicated  file  (a  Class  4  event) 
with  only  the  requested  data  filled  in.  If  the  response  comes  from 
a  populated  module  it  will  be  routed  through  the  controller,  other¬ 
wise,  it  will  be  sent  directly  to  the  requesting  module.  Responses 
will  be  subject  to  delays  and  the  information  may  be  degraded  to 
represent  realisitc  response  times  and  inaccuracies  inherent  in 
manually  recording  information. 

The  last  category  of  events  within  this  grouping  of  Class  2 
events  is  the  retransmit  event.  The  retransmit  event  provides  staff 
modules  the  capability  to  retransmit  any  received  message  to  the  com¬ 
mand  module  or  another  staff  module  as  deemed  appropriate.  This  will 


occur  when  the  content  of  the  message  is  time  sensitive  or  of  surh 
impact  that  ttie  use  of  normal  channels  may  adversely  affect  the  -  le¬ 
sion  of  the  division.  Retransmi t La  1 s  of  a  received  message  are 
only  allowed  when  the  desired  recipient  (as  determined  ty  the  re¬ 
ceiving  module)  is  not  on  the  initial  distribution  list.  The  tacti¬ 
cal  information  messages  which  may  be  retransmitted  bv  a  uarti > ul ar 
staff  module  are  as  indicated  in  Design  Note  A. 

G.2.5  Miscellaneous  Events 

There  are  two  events  which  do  not  fit  neatly  into  these  group¬ 
ings  as  discussed  above.  These  two  events  are  th^  Decision  by  the 
Command  Group  Module  and  the  Post  Strike  Analysis  by  the  Fire  Support 
Element  Module.  A  decision  by  the  Command  Module  is  an  outout  of  the 
Command  Module  to  one  or  core  of  the  principal  staff  modules.  A  de¬ 
cision  by  a  simulated  Command  Module  will  only  be  nrovided  in  response 
to  a  request  for  release  of  a  frag  order  by  one  of  the  principal  staff 
modules.  For  example,  a  simulated  or  populated  G3  module  may  determine 
that  it  is  opportune  to  commit  a  portion  of  the  organic  reserves.  If 
that  portion  broaches  a  certain  threshold  as  established  by  the  com¬ 
manders  guidance,  then  the  G3  would  send  a  completed  frag  order  (di¬ 
recting  the  commitment  of  the  reserves)  to  the  Command  Module  will 
consist  of  the  format  being  returned  to  the  G3  with  permission  being 
either  granted  or  denied.  A  populated  Command  Module  may  provide  a 
decision  to  staff  modules  in  this  same  manner.  In  addition,  however, 
a  populated  Command  Module  may  initiate  a  decision.  This  decision 
will  be  in  the  form  of  a  completed  fraq  order  transmitted  to  the  ap¬ 
propriate  staff  module  directing  that  it  be  output  by  the  Fire  Support 
Element  Module,  populated  or  simulated,  only  after  a  nuclear  strike 
has  been  authorized  and  completed  within  the  division  area  of  inter¬ 
est  The  Post  Strike  Analysis  will  be  based  upon  the  post  strike 
damage  reports  from  subordinate  and  adjacent  units  and  will  be  used 
in  the  decision  process  of  the  command,  G2  and  G3  modules. 

G . 2 . 6  Error  Detection 

The  Class  2  events,  as  discussed  in  the  preceding  paragraphs, 
represent  the  continuous  and  informal  coordination  and  "staffing"  pro¬ 
cess  that  occurs  on  a  division  staff  as  a  result  of  staff  action  or 
interaction.  Any  internal  requirements  in  staff  actions  are  effected 
by  these  message  exchange  events.  Every  messane  exchange  of  this 
kind  will  have  to  be  carefully  edited  and  interpreted  by  the  control¬ 
lers)  and/or  computer  before  the  change  is  instituted  in  the  real 
world  data  base.  If  the  message  contains  any  ambiguities  or  logical 
inconsistencies  associated  with  the  war  game  variables,  the  con- 
troller(s)  and/or  computer  must  simulate  the  request  for  clarifica¬ 
tion  back  to  the  staff  module  and  wait  for  a  consistent  message. 


G. 3  DISCUSSION  OF  APPENDIX  G-l 

All  Class  2  events  are  identified  in  Appendix  G-l.  The 
identification  of  a  Class  2  event  includes  the  event  number,  the  tac¬ 
tical  information  message  included  in  the  event,  the  preparina  module, 
the  module  version  (populated  and  simulated  or  populated)  capable 
of  preparing  the  messaqe,  and  the  receivinq  modules.  The  ejvent  num¬ 
ber  consists  of  the  one  digit  event  class  plus  the  two  digit  reference 
number  associated  with  each  tactical  information  message  listed  in 
Design  Note  A.  Specific  formats  for  each  of  these  Class  2  events  are 
contained  in  Design  Note  D  where  they  are  listed  -ty/  reference  number. 
Notes  on  specific  categories  of  messages  are  included  in  the  Appendix. 


G-l  1 


Appendix  G-1 
CLASS  2  EVENTS 


EVENT 

NO. 

EVENT 

FROM 

MODULE 

VERSION 

TO1 

201 

-QUERY 

CMD 

POP/SIM 

SELECTED  STAFF 

202 

^JUC  REL  REQ 

CMD 

POP/SIM 

G3 

203D 

MSN  ANAL 

CMD 

POP 

ALL  LIVE  STAFF 

2040 

CMDR  GUID 

CMD 

POP 

ALL  LIVE  STAFF 

205 

CMDR  DEC 

CMD 

POP/SIM 

SELECTED  STAFF 

2XX 

RETRANSMIT 

CMD 

POP/SIM 

SELECTED  STAF' 

210 

-QUERY 

FSE 

POP/SIM 

SELECTED  STAFF 

212 

If RAG  ORDER  (FS) 

FSE 

POP/SIM 

ALL  STAFF 

213 

fOIR  FIRE  SPT 

FSE 

POP/SIM 

G3 

214 

^PPR  FIRE  SPT 

FSE 

POP/SIM 

G3 

215 

-ARTY  SITREP 

FSE 

POP/SIM 

LIVE  G3/G1/G4 

216 

TGT  LIST  (ARTY) 

FSE 

POP/SIM 

G2/G3 

217 

FU  FIRE  SPT  CAP 

FSE 

POP/SIM 

G3 

218 

EU  FIRE  SPT  CAP 

FSE 

POP/SIM 

G2/G3 

219 

POST  STRIKE  ANAL 

FSE 

POP/SIM 

CMD/G2/G3 

220D 

FIRE  SPT  ANNEX 

FSE 

POP 

LIVE  G3 

221 

REQUEST 

FSE 

POP/SIM 

SELECTED  STAFF 

222 

RESPONSE 

FSE 

POP/SIM 

SELECTED  STAFF 

2XX 

RETRANSMIT 

FSE 

POP/SIM 

SELECTED  STAFF 

230 

-QUERY 

G2 

POP/SIM 

SELECTED  STAFF 

232 

IfRAG  ORDER  (I) 

G2 

POP/SIM 

ALL  STAFF 

233D 

foiV  INTSUM 

G2 

POP 

ALL  LIVE  STAFF 

234 

=N8C  REPORT 

G2 

POP/SIM 

ALL  STAFF 

235 

,WX  FORECOST 

G2 

POP/SIM 

ALL  STAFF 

236 

-INPUT  TO  DIV  SITREP 

G2 

POP/SIM 

LIVE  G3 

237D 

INTELL  EST 

G2 

POP 

ALL  LIVE  STAFF 

238D 

INTELL  ANNEX 

G2 

POP 

LIVE  G3 

239 

REQUEST 

G2 

POP/SIM 

SELECTED  STAFF 

240 

RESPONSE 

G2 

POP/SIM 

SELECTED  STAFF 

2XX 

RESTRANSMIT 

G2 

POP/SIM 

SELECTED  STAFF 

250 

-QUERY 

G3 

POP/SIM 

SELECTED  STAFF 

252 

If RAG  ORDER  (OPS) 

G3 

POD/SIM 

ALL  STAFF 

253D 

fOIV  SITREP 

G3 

POP 

ALL  LIVE  STAFF 

254 

§NUC  WARNING  ORDER 

G3 

POP/SIM 

ALL  STAFF 

255 

fAD  WARNING 

G3 

POP/SIM 

ALL  STAFF 

2570 

--0P  PLAN 

G3 

POP 

ALL  LIVE  STAFF 

258D 

OP  EST 

G3 

POP 

ALL  LIVE  STAFF 

259 

INITIAL  EN  CONT 

G3 

POP/SIM 

CMD/G2 

260 

UNIT  PROG  RPT 

G3 

POP/SIM 

CMD 

261 

LOSS  CONT  W/FU 

G3 

POP/SIM 

CMD/FSE 

262 

EOOB 

G3 

POP/SIM 

G2/FSE 

263 

REQUEST 

G3 

POP/ SIM 

SELECTED  STAFF 

264 

RESPONSE 

G3 

POP/SIM 

SELECTED  STAFF 

2XX 

RETRANSMIT 

G3 

POP/SIM 

SELECTED  STAFF 

EVENT 

NO. 

EVENT 

FROM 

MODULE 

VERSION 

TO1 

280 

-QUERY 

G1/G4 

POP/SIM 

SELECTED  STAFF 

282 

ffRAG  ORDER  (CSS) 

G1/G4 

POP/SIM 

ALL  STAFF 

283D 

§DIV  PDS 

G1/G4 

POP 

LIVE  CMD 

284D 

|rer  log  rpt 

G1/G4 

POP 

LIVE  CMD 

2850 

=-PERS  REQ 

G1/G4 

POP 

LIVE  CMD/G3 

287 

CSS  EST 

G1/G4 

POP 

ALL  LIVE  STAFF 

288D 

CSS  ANNEX 

G1/G4 

POP 

LIVE  G3 

289 

REQUEST 

G1/G4 

POP/SIM 

SELECTED  STAFF 

290 

RESPONSE 

G1  /G4 

POP/SIM 

SELECTED  STAFF 

2XX 

RETRANSMIT 

G1/G4 

POP/SIM 

SELECTED  STAFF 

Selected  Staff  or  All  Staff  includes  the  commander,  if  appropriate. 

2 

These  messages  are  represented  by  Class  3  events  and  are  distributed 
to  the  staff  for  information 
3 

These  messages  are  only  produced  if  required  by  a  populated  G3  module. 


DESIGN  NOTE  H 


GENERAL  DISCUSSION  OF  CLASS  5  EVENTS 
WITH  SPECIAL  EMPHASIS  ON  INTELLIGENCE  FUNCTIONS 

H.l  INTRODUCTION 

Class  5  events  represent  all  significant  occurrences  taking 
place  in  the  interior  modules  of  the  simulation.  These  events  include 
not  only  the  actual  maneuvers,  engagements,  and  intelligence  collec¬ 
tion  activities  by  units  of  the  opposing  forces  but  also  all  follow- 
on  events  to  Class  3  staff  outputs  and  progenitors  for  Class  4  staff 
inputs . 


The  former  type  events--unit  maneuvers,  combat  engagements, 
target  detections,  electronic  warfare,  intelligence  collection  and 
processing--are  called  "battle-related"  Class  5  events.  These  events 
have  no  direct  relationship  with  the  separately  defined  tactical  in¬ 
formation  messages  described  in  Design  Notes  A  thru  G  and,  therefore, 
do  not  conform  to  the  rule  about  embedded  message  reference  numbers 
used  in  Section  4.1.  Class  5  events  of  this  type  are  instead  assigned 
numbers  that  fall  into  the  unused  spaces  in  the  range  500-599. 

The  progenitors  and  follow-on  events,  on  the  other  hand,  are 
associated  with  specific  tactical  messages  and  are  called  "report- 
related"  Class  5  events.  These  events  do  conform  to  the  embedded 
reference  number  rule  even  though  they  are  not  themselves  interface 
events.  Such  report-related  Class  5  events  exist  for  all  defined 
tactical  messages  except  those  dealing  solely  with  staff  coordination 
exchanges . 

The  event  numbers  and  definitions  of  the  Class  5  events  iden¬ 
tified  to  date  are  shown  in  Table  H-l.  The  table  specifies  12  battle- 
related  events  and  61  report-related  events.  The  battle-related 
events  are  marked  with  asterisks.  As  additional  events  of  this  type 
are  defined,  they  will  be  inserted  in  the  unused  spaces  in  the  table. 

This  Design  Note  presents  a  general  discussion  of  Class  5 
events  with  special  emphasis  on  the  intelligence  functions  that  will 
be  simulated  as  part  of  the  division-level  combat.  Since  these  Class 
5  events  follow  from  the  relationship  between  the  ground  truth  facts 
carried  in  the  Real  World  Data  Base  and  the  perceptions  stored  in  the 
Blue  or  Red  Perceived  Data  Bases,  the  discussion  will  begin  by  showing 
the  proposed  structure  and  organization  of  a  computer  file  combining 
the  principal  data  groups  of  these  three  data  bases.  Within  this 
framework,  the  battle-related  Class  5  events  that  affect  the  ENSIT 
data  are  identified,  and  the  method  of  simulating  intelligence 
collection/processing  functions  is  explained.  The  discussion  will 
then  turn  to  the  report-related  Class  5  events  and  show  how  the 


Table  H-l.  Class  5  Events. 


I 

Event  Number  Definition  of  Event  j 


Battle  Events 

500*  Battlefield  clock  indicates  it  is  time  to  initiate  ordered  action. 

501  Addressee  receives  Query  from  Command  Grouo. 

502  Corps  receives  Nuclear  Release  Request. 

503*  Unit(s)  begin  moving. 

504*  Unit(s)  cross  phase  line  or  check  point. 

505*  Unit(s)  close  at  destination. 


508*  Engagement  Phase  nn;  Battle  Array  nnn. 

510  Addressee  receives  Query  from  FSE. 

511  Corps  receives  Query  on  its  Frag  Order  (FS). 

512  Addressee  receives  Frag  Order  (FS). 

513  Corps  receives  Immediate  Request  for  Fire  Support. 

514  Corps  receives  Preplanned  Request  for  Fire  Support. 

515  Preparation  of  Arty  Sitrep. 

516  Preparation  of  Arty  Target  List. 

517  Preparation  of  Friendly  Unit  Fire  Support  Capability. 

518  Preparation  of  Enemy  Unit  Fire  Support  Capability. 

519*  Enemy  target  attacked  by  conventional  weapons. 

520*  Enemy  target  attacked  by  nuclear  weapon. 


523  Preparation  of  Immediate  Request  FS. 

524  Preparation  of  Preplanned  Request  FS. 

525  Preparation  of  Target  Report  (Intel). 

526  Preparation  of  Fire  Support  Status  Report. 

528  Preparation  of  Fire  Support  Estimate/Annex. 

529  Corps  xmits  Frag  Order  (FS). 

530  Addressee  receives  Query  from  G2. 

531  Corps  receives  Query  on  its  Frag  Order  (Intel). 

532  Addressee  receives  Frag  Order  (Intel). 

533  Corps  receives  Division  Intsum. 

534  Preparation  of  NBC  Report  or  Corps  receipt  thereof. 

535  Preparation  of  Weather  Forecast. 

536*  Friendly  unit(s)  attacked  by  conventional  weapons. 

537*  Friendly  unit(s)  attacked  by  nuclear  weapon. 

538*  Assessment  of  damage  from  conventional  weapons. 

539*  Assessment  of  damage  from  nuclear  weapons. 

540*  Intelligence  Received. 

541  Preparation  of  Bde  Intsum. 


Event  number  contains  no  embedded  message  reference  number. 


H-2 


Table  H-1.  Class  5  Events  (Conti need). 


Event  Number 


Definition  of  Event 


Battle  Events  -  continued 

542  Preparation  of  Shell  Report. 

543  Preparation  of  Spot  Report. 

544  Preparation  of  Combat  Intelligence  Report. 

545  Preparation  of  Post  Strike  Damage  Report. 

546  Preparation  of  Estimate  of  Enemy  Strength. 

547  Preparation  of  Target  List  (Intel). 


549  Corps  xmits  Frag  Order  (Intel). 

550  Addressee  receives  Query  from  G3. 

551  Corps  receives  Query  on  its  Frag  Order  (OPS). 

552  Addressee  receives  Frag  Order  (OPS). 

553  Corps  receives  Division  Sitrep. 

554  Addressee  receives  Nuclear  Warning  Order. 

555  Addressee  receives  Air  Defense  Warning  Order. 

556  Corps  receives  Request  for  Reserves. 

557  Corps  receives  Operations  Plan. 


559 

560 

561 

562 


Preparation 

Preparation 

Preparation 

Preparation 


of  Initial  Enemy  Contact  Report, 
of  Unit  Progress  Report, 
of  Loss-of-Contact/Friendly  Unit  Report, 
of  Enemy  Electronic  Order  of  Battle. 


565 

566 

567 


Preparation 

Preparation 

Preparation 


of  Bde/Bn  Sitrep. 

of  Air  Defense  Alert. 

of  Organic  Aviation  Sortie  Status  Report. 


571  Corps  xmits  Frag  Order  (OPS). 

572  Preparation  of  Operations  Special  Estimate/ Annex . 


580  Addressee  receives  Query  from  Gl/64. 

581  Corps  receives  Query  on  its  Frag  Order  (CSS). 

582  Addressee  receives  Frag  Order  (CSS). 

583  Corps  receives  Division  Personnel  Daily  Summary. 


1 

t 


Table  H-l.  Class  5  Events  (Continued). 

Event  Number  Definition  of  Event 

Battle  Events  -  continued 

584  Corps  receives  Periodic  Logistics  Report. 

585  Corps  receives  Personnel  Requisition. 

586  Preparation  of  Immed.  Req.  for  Logistic  Support  or  Corps  receipt. 


591  Preparation  of  Bde/Bn  Personnel  Daily  Summary. 

592  Preparation  of  CAPE  Report. 

593  Preparation  of  Preplanned  Request  for  Logistic  Support. 


595  Corps  xmits  Frag  Order  (CSS). 

596  Preparation  of  DisCom  Sitrep  or  Corps  receipt  thereof. 

597  Preparation  of  CMO  Estimate/Annex. 


intelligence  staff  inputs  (Class  4)  will  be  generated  by  processing 
the  real  world  data  by  means  of  the  state-of-knowledge  indices  from 
the  ENSIT  table  and  then  aggregating  the  intelligence  data  according 
to  the  report  format  requirements. 

This  Design  Note  is  intended  to  provide  a  perspective  on  the 
manner  in  which  the  intelligence  functions  will  be  simulated.  The 
reviewer  should  bear  in  mind  that  the  full  range  of  battle-related 
Class  5  events  having  no  relationship  to  intelligence  are  not  fully 
defined  nor  are  the  report-related  Class  5  events  bearing  on  FRENSIT 
tables  full  developed. 

H.2  STRUCTURE  OF  THE  COMBINED  DATA  BASE 

The  basic  design  concept  of  the  integrated  battle  simulation 
specified  three  distinct  data  bases:  the  Real  World  Data  Base,  the 
Blue  Perceived  Data  Base,  and  the  Red  Perceived  Data  Base.  The  Real 
World  Data  Base  contains  the  simulation  status  variables  for  each 
company-sized  unit  in  both  the  Blue  and  Red  forces;  the  perceived 
data  bases  each  contain  Enemy  Situation  (ENSIT)  and  Friendly  Situation 
(FRENSIT)  data  tables  representative  of  the  state  of  knowledge  the 
Blue  or  Red  side  holds  about  the  enemy  situation  and  about  its  own 
forces  (see  Section  4.1.3).  These  data  bases  are  further  defined 
and  partitioned  as  follows: 

•  Real  World  Data  Base 

-  Reference  Table 

-  Real  World  Unit  Type  Table 

-  Battle  Array  File 

-  Real  World  Status  Data 

•  Blue  Perceived  Data  Base 

-  Enemy  Situation  File 

-  Friendly  Situation  File 

•  Red  Perceived  Data  Base 

-  Enemy  Situation  File 

-  Friendly  Situation  File 

With  the  one  exception  of  the  Reference  Table,  which  will  be  located 
in  core  memory,  all  of  the  above  files  will  be  located  in  direct-access 
memory.  Table  H-2  specifies  the  entries  required  in  the  Reference 
Table  for  each  of  the  allowable  300  units  of  the  simulation.  The 
Reference  Table  contains  all  search  variables  (by  any  entry)  whereby 
access  is  gained  to  those  files  located  in  direct-access  memory.  Those 
entries  that  are  invariant  once  the  play  of  the  game  has  commenced  are 
indicated  by  an  I  while  those  variable  entries  are  indicated  by  a  V. 

The  field  size  is  specified  for  each  entry  in  the  Reference  Table,  thus 


implying  that  7200  bytes  or  characters  are  required  for  the  300  units 
in  the  Reference  Table. 


Table  H-2.  Core  Reference  Table. 


ENTRY 

CHANGEABLE 

FIELD  SIZE 

ACCUMULATIVE 

Unit  Identification 

I 

10 

10 

Unit  Type  Index 

I 

2 

12 

Current  Task  Organization 

V 

2 

14 

Current  Location 

V 

8 

22 

Battle  Array  Index 

V 

2 

24 

The  Real  World  Unit-Type  Table  consists  of  those  standard  data 
which  must  be  specified  for  each  unit  (Red  and  Blue)  within  the  simula¬ 
tion.  Up  to  25  unit  type  entries  may  be  listed  for  each  opposing  force. 
Unit  type  tables  for  different  type  units  are  expected  to  reflect  a 
great  deal  of  commanlity,  however,  there  will  also  be  differences  to 
reflect  their  unique  missions,  weapons,  and  equipments. 

•  Authorized  strength 

•  Weapon  quantity  and  types 

§  Weapon  ammunition  expenditure  rate 

•  Ammunition  basic  load  (by  weapon  type/activity) 

•  Equipment  quantity  and  types 

•  POL  basic  load 

•  POL  expenditure  rate  (by  equipment  type/activity) 

•  Firepower  coefficients 

•  Units  communicability  index 

It  is  estimated  that  each  unit  type  entry  will  require  120  bytes, 
making  the  total  requirements  for  the  subtable  3000  bytes. 

The  Battle  Array  File  will  contain  arrays  of  data  identifying 
specific  maneuver  units  and  combat  support  units  on  each  side  during 
the  time  the  opposing  forces  are  engaged  in  active  combat.  Separate 
arrays  will  exist  for  different  battles  taking  place  in  different  loca¬ 
tions  in  the  tactical  area  of  play.  An  individual  battle  array  will  be 
created  whenever,  during  the  play  of  the  game.  Blue  units  and  opposing 
Red  units  first  make  contact.  The  array  data  will  remain  on  file  until 
the  engagement  is  resolved  and  the  opposing  forces  have  broken  off 
contact.  In  addition  to  the  units  in  contact,  current  firepower  scores, 
unit  center  of  mass,  and  other  like  variables  will  be  maintained  in  this 
file  for  ready  access. 
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For  the  initial  implementation  of  the  design  concept,  it  is 
proposed  that  the  remaining  data  bases  be  combined  into  a  single 
direct-access  computer  disk  file  keyed  by  a  unit  index.  The  structure 
of  this  file  is  shown  in  Figure  H-l. 

The  file  will  consist  of  300  records  of  approximately  300  bytes 
or  characters  each.  The  records  will  be  keyed  by  a  unit  index  varying 
between  1  and  300.  Unit  indeces  1  to  150  will  cover  the  company-sized 
units  of  the  Blue  force;  the  indices  151  to  300  the  Red  force.  Each 
record  will  contain  approximately  200  bytes  of  real  world  status  infor¬ 
mation  plus  50  bytes  each  for  the  FRENSIT  data  and  ENSIT  data  associated 
with  the  unit.  In  the  sample  entries  shown  in  the  figure,  record  53 
will  contain  the  status,  location,  etc.,  of  the  53rd  Blue  unit  as  well 
as  the  Blue  and  Red  perceptions  of  the  same  unit.  Similarly,  record 
195  will  contain  the  corresponding  groups  of  information  for  the  45th 
Red  unit  in  the  war  game.  The  tabular  array  of  data  heretofore  identi¬ 
fied  as  the  Blue  Perceived  Data  Base  is  now  more  fully  defined  as  the 
FRENSIT  information  over  the  first  150  records  and  the  ENSIT  data  in 
the  last  150  records.  It  is  shown  by  the  shaded  boxes.  The  Red  Per¬ 
ceived  Data  Base  is  simply  the  remaining  unshaded  portion  on  the  right. 

It  can  been  seen  by  comparing  the  relative  sizes  of  the  real 
world  status  variables  and  the  FRENSIT  or  ENSIT  data  that  the  state 
of  knowledge  materiel  is  stored  by  the  use  of  special  coded  variables 
and  is  not  simply  a  biased  or  degraded  version  of  the  same  data  on 
the  left.  The  special  variables  will  consist  of  perceived  status 
indicators,  state-of-knowledge  indices,  and  reporting  time  parameters. 

A  state-of-knowledge  ($0K)  index  will  be  a  one-digit  integer  whose 
value  will  be  a  quantitative  measure  of  the  current  state  of  knowledge 
about  an  item  of  friendly  or  enemy  force  information.  The  reporting 
time  parameters  will  be  simply  the  recorded  date-time-groups  when 
the  statement-of-knowledge  indices  were  last  updated  by  means  of  intelli¬ 
gence  processing  events.  The  special  codes  will  provide  the  basis 
for  a  compressed  data  storage  format  as  well  as  for  the  algorithms 
which  will  govern  the  biasing  or  degrading  of  the  tactical  informa¬ 
tion  held  by  the  two  sides. 

The  algorithms  or  routines  controlling  the  SOKs  will  be  rooted 
to  a  set  of  internal  tables  relating  the  SOK  values  to  the  amount  or 
interpretation  of  the  error  by  which  the  perceived  facts  depart  from 
the  real  facts.  There  will  be  a  separate  table  for  each  identified 
item  of  friendly  or  enemy  force  information.  For  example,  there  will 
be  a  location  SOK  table  showing  the  range  of  probable  location  errors 
ascribed  to  each  of  the  ten  values  of  the  location  SOK  index.  By  re¬ 
ference  to  these  tables,  the  routines  will  be  able  to  generate  or  change 
aspects  of  the  state  of  knowledge  held  by  the  Blue  or  Red  sides. 
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Figure  H-l.  Structure  of  File  Combining  Principal  Data  Groups  of  the  Three  Data  Bases 


H.2.1  Real  World  Status  Data 


Nearly  all  Class  5  events,  whether  battle-related  or  report- 
related,  will  refer  to,  or  be  associated  with,  one  or  more  units  of 
the  Blue  and/or  Red  forces.  Exceptions  are  those  miscellaneous  events 
associated  with  the  weather,  sunrise/sunset,  terrain-oriented  targets, 
etc.  Generally,  battle-related  events  will  cause  changes  in  the  Real 
World  Status  Data  and  the  ENSIT  files  of  the  opposing  forces,  and 
report-related  events  will  (1)  cause  changes  in  the  FRENSIT  files,  (2) 
maintain  cognizance  of  times  associated  with  the  preparation  and  trans¬ 
mission  of  reports  and,  in  some  instances,  (3)  also  cause  changes  in 
the  Real  World  Status  Data. 

As  mentioned  previously,  the  Real  World  Status  Data  for  each 
unit  will  be  contained  in  the  first  200  bytes  of  the  record  associated 
with  that  unit  in  the  combined  file  of  Figure  H-l.  Table  H-3  con¬ 
tains  a  preliminary  list  of  these  status  variables  and  their  required 
field  sizes  for  a  Blue  mechanized  infantry  company.  This  list  will 
be  refined  as  the  model  is  developed  and  similar  lists  will  be  pre¬ 
pared  for  each  Blue  and  Red  unit  type.  It  should  be  noted  that  al¬ 
though  the  list  of  status  variables  will  be  the  same  for  a  particular 
type  unit,  the  data  values  for  these  variables  will,  in  all  likelihood, 
be  different  for  each  specific  unit. 

An  analysis  of  the  Real  World  Status  Data  for  the  Blue 
mechanized  infantry  company  reveals  the  following  information: 

•  To  date,  there  are  55  status  variables  and  15  status 
flags  assigned,  of  which 

Fifteen  variables  have  been  identified  to  record 
the  three  primary  weapons  assigned  and  the  cur¬ 
rent  available  ammunition. 

Fourteen  variables  have  been  identified  to  record 
the  current  posture,  activity,  missions,  communi¬ 
cability,  and  location. 

Thirteen  variables  have  been  identified  to  record 
the  four  primary  vehicles  assigned  and  POL. 

Eight  variables  have  been  identified  to  record 
the  task  organization  and  current  personnel  assets. 

Five  variables  have  been  identified  to  record  re¬ 
port  submission  times. 

•  There  are  34  spare  bytes  which  may  be  used  to  store  ad¬ 
ditional  variables  which  might  be  required. 

•  That  with  the  one  exception  of  one  future  mission  and 
its  associated  time  all  status  variables  reflect  current 
information . 
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Table  H-3.  Real  World  Status  Data  for  a  Mechanized  Infantry  Company 


STATUS  VARIABLE 


FIELD 

SIZE  ACCUMULATIVE 


Status  Flags  (15  to  be  specified) 

Current  Posture 

Current  Activity 

Current  Communicability 

Current  Primary  Mission 

Current  Intelligence  Mission 

Next  Primary  Mission 

Current  Movement  Rate 

Current  Direction  of  Movement 

Right  Adjacent  Unit  Index 

Left  Adjacent  Unit  Index 

Next  Task  Organization 

Current  Total  Personnel  Strength 

Personnel  Gains  Since  DTG1 

KIA 

WIA 

MIA 

Weapon  Type  1 :  Operable 
Lost/Destroyed 
Damaged/Failed 
Expected  Up  Next  Period? 

Current  Ammo  Load 
Weapon  Type  2:  Operable 
Lost/Destroyed 
Damaged/Failed 
Expected  Up  Next  Period 
Current  Ammo  Load 
Weapon  Type  3:  Operable 
Lost/Destroyed 
Damaged/Failed 
Expected  Up  Next  Period? 

Current  Ammo  Load 
Vehicle  Type  1:  Operable 
Lost/Destroyed 
Damaged/Failed 
Expected  Up  Next  Period? 
Vehicle  Type  2:  Operable 
Lost/Destroyed 
Damaged/Failed 
Expected  Up  Next  Period? 
Vehicle  Type  3:  Operable 
Lost/Destroyed 
Damaged/Failed 
Expected  Up  Next  Period? 


2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 

2 


2 

4 

6 

8 

10 

12 

14 

16 

18 

20 

22 

24 

26 

28 

30 

32 

34 


44 


54 


64 


72 


80 


88 
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Table  H-3.  Real  World  Status  Data  for  a  Mechanized  Infantry  Company 
(Continued) . 


STATUS  VARIABLE 

FIELD 

SIZE 

ACCUMULATIVE 

Vehicle  Type  4:  Operable 

2 

Lost/L)estroyed 

2 

Damaged/ Failed 

2 

Expected  Up  Next  Period? 

2 

96 

Current  Qty  POL 

2 

98 

DTG1  Last  Personnel  Daily  Summary 

4 

102 

DTG2  Last  SITREP 

4 

106 

DTG3  Next  Mission/Task  Orq  Change 

4 

no 

DTG4  Expctd  Phse  Line/Chk  Pt/Closing 

4 

114 

DTG5  Last  CAPE 

4 

118 

Next  Location 

8 

126 

Center  of  Mass  Location 

8 

134 

PT1  of  Contact 

8 

142 

PT2  of  Contact 

8 

150 

PT3  of  Contact 

8 

158 

PT4  of  Contact 

8 

166 
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•  That  the  Real  World  Status  Data  reflects  current  data 
required  by  senior  echelons  of  each  subordinate  unit 
to  command  and  control  combat  assets. 

The  status  variables  for  each  unit  within  the  Real  World  Status 
Data  will  be  updated  as  a  result  of  a  battle-related  event  or  a  report- 
related  event.  Prior  to  an  engagement,  battle-related  events  500,  503, 
504,  and  505  and  other  events  yet  to  be  defined  will  cause  updates  to 
associated  status  variables  upon  the  occurrence  of  that  event.  There 
will  be  a  validity  check  on  certain  events  to  ensure  that  they  have 
indeed  occurred.  For  example,  if  an  event  initiated  the  movement  of 
a  maneuver  company  from  checkpoint  A  to  checkpoint  B,  a  search  algorithm 
within  the  event  processing  would  ensure  that  any  event  intervening 
with  the  unit  prior  to  the  arrival  event  would  cause  the  arrival  event 
to  be  invalid.  This  check  would  be  accomplished  prior  to  the  unit's 
arrival  at  checkpoint  B  being  posted.  This  mechanism  is  referred  to  as 
the  "not-really"  property  within  the  event-store  simulation. 

An  engagement  event  508  will  cause,  inter  alia,  updates  to 
associated  status  variables  for  those  units  that  suffer  personnel  and 
materiel  losses  at  the  end  of  each  15  minute  phase  of  the  engagement. 
Battle-related  events  519,  520,  536,  and  537  will  cause  updates  to  the 
associated  status  variables  upon  their  occurrence.  The  "not  really" 
mechanism  will  be  used  to  validate  the  occurrence  of  these  events. 
Battle-related  events  538,  539,  and  540  do  not  cause  changes  to  any 
field  within  the  Real  World  Status  Data  but  do  operate  on  the  Ef.SIT 
file  as  will  be  explained  in  paragraph  H.3.2.  There  are  six  report- 
related  events,  defined  to  date,  which  cause  updates  cr  changes  to  unit 
status  variables  within  the  Real  World  Status  Data.  There  are  events 
512,  532,  552,  554,  555,  and  582.  These  Class  5  events  represent  the 
receipt  of  various  frag  and  warning  orders  by  specific  units  within 
the  BOG.  Frag  orders  may  indicate  a  change  in  a  unit's  mission/task 
organization  or  it  may  indicate  replacements  or  replenishment.  Appro¬ 
priate  status  variables  will  be  changed  upon  receipt.  Warning  orders 
may  result  in  a  unit's  posture  or  activity  being  degraded  and,  as  before, 
appropriate  status  variables  will  be  changed  upon  receipt. 

H.2.2  Perceived  Status  Data 


As  mentioned  previously,  the  Perceived  Status  Data  is  organized 
within  the  last  100  bytes  of  the  individual  records  presented  in  Figure 
H-l.  The  Blue  Perceived  Data  Base,  i.e.,  the  Blue  perception  of  its 
own  and  the  opposing  forces,  consists  of  the  union  of  FREfJS I T  informa¬ 
tion  over  the  first  150  records  and  the  ENS IT  information  in  the  last 
150  records.  Conversely,  the  Red  Perceived  Data  Base  consists  of  the 
union  of  ENSIT  information  over  the  first  150  records  and  the  FRENSIT 
information  in  the  last  150  records. 
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The  FRENSIT  record  for  each  unit  will  consist  of  a  set  of  SDK 
indices  which  delineate  the  unit’s  combat  effectiveness  and  a  set  of 
perceived  status  flays.  The  SuK  indices  and  perceived  status  flags, 
although  not  fully  developed,  are  not  expected  to  differ  significantly 
between  each  type  unit.  For  example,  SOK  indices  have  been  defined 
for  the  following  variables  representing  a  mechanized  infantry  company: 
vehicles,  POL,  weapons,  ammunition,  personnel,  and  location.  All  of 
the  real  world  status  data  concerning  vehicles  in  Table  H-3  will  be 
reflected  by  a  single  SOK  index.  Accordingly,  a  SOK  value  of  nine 
would  signify  that  the  division  staff  has  current  and  accurate  knowledge 
of  the  four  type  vehicles  contained  within  the  company  (to  include 
number  and  type  vehicles,  damage  received,  status  of  repair,  etc.), 
while  a  SOK  values  of  zero  would  signify  that  the  division  staff  has 
no  knowledge  about  the  company's  vehicles.  This  latter  value  would 
ordinarily  not  happen  for  a  friendly  force  and  is  only  presented  tc 
indicate  the  extreme  case.  Similar  logic  can  be  used  to  describe 
fully  each  variable  for  which  a  SOK  index  has  been  defined.  It  is 
apparent  that  these  variables  could  be  readily  extended  to  reflect 
other  type  units  although  it  is  expected  that  separate  SOK  indices 
will  be  defined  for  support  and  headquarter  units.  A  cursory  inspec¬ 
tion  reveals  that  they  are  applicable  to  artillery  and  air  defense  artil¬ 
lery  units  as  well.  It  should  be  noted  that  the  real  world  status  data 
for  these  different  units  will  differ  significantly  and  the  SOK  indices 
only  reflect  the  perceived  knowledge  about  each  category. 

The  ENSIT  record  for  each  unit  will  also  consist  of  a  set  of 
SOK  indices  and  a  set  of  perceived  status  flags.  These  indices  and 
flag  variables  are  not  yet  fully  developed,  but  are  expected  to  cover 
intelligence  information  categories  about  the  unit  which  are  pertinent 
to  the  intelligence  collect  and  processing  used  by  the  Blue  and  Red 
sides.  One  category,  for  example,  will  be  related  to  the  size  of  the 
enemy  unit  -  is  the  unit  as  isolated  body  no  larger  than  company  size? 

Is  it  part  of  a  battalion-sized  force  or  even  a  brigade  or  regiment? 

A  SOK  value  of  nine  in  this  category  would  signify  ttiat  the  size  of  the 
enemy  force  had  been  reliably  and  accurately  determined,  while  a  SOK 
value  of  zero  would  mean  that  the  sensor  detection  had  provided  no 
clue  whatsoever  about  the  size  of  the  enemy  unft.  Similar  logic  can 
be  used  in  other  categories  of  ENSIT  information. 

H.3  CLASS  5  EVENTS  INVOLVING  INTELLIGENCE  COLLECTIuN  AND  PROCESSING 

For  the  purposes  of  simulating  the  intelligence  collection  and 
processing  on  the  opposing  sides,  the  ENSIT  data  in  the  perceived  data 
bases  will  be  controlled  and  updated  by  computer  logic  which  will  al¬ 
ways  divide  incoming  intelligence  information  into  the  two  categories: 
"contact  intelligence"  and  "sensor  detections." 
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Contact  intelligence  is  defined  as  the  development  of  intelli¬ 
gence  about  the  opposing  side  by  forces  directly  engaged  in  combat 
(e.g.,  maneuver  brigades,  battalions,  or  any  grouping  of  units  con¬ 
tained  in  a  battle  array).  The  influx  of  contact  intelligence  will  be 
handled  by  logic  within  the  routines  of  event  No.  508  (basic  engagement 
event).  The  collection  and  processing  of  intelligence  about  the  op¬ 
posing  side  will  otherwise  not  be  explicitly  simulated,  but  instead 
will  be  governed  by  an  algorithm  which  updates  the  ENSIT  data  for  all 
enemy  units  contained  in  the  battle  array.  This  is  described  below 
in  Paragraph  H.3. 1 . 

Sensor  detections,  on  the  other  hand,  are  defined  as  all  other 
incoming  intelligence  information.  Sensor  detections  will  be  explicitly 
simulated  as  stemming  from  the  following  sources: 

•  Flank  guard  elements 

•  Forward  observers 

•  Special  intelligence  sources 

•  UGSs 

t  RPVs 

t  Air  reconnaissance 

•  Agents/LRRPs 

•  SOTAS 

•  GSR 

•  Counter  Battery  Radars 

•  POW/Humint 

•  Reconn  patrols 

•  Air  cavalry  elements 

The  defined  battle-related  Class  5  events  in  which  these  explicit  detec¬ 
tions  will  take  place  have  not  yet  been  identified.  Some  detections 
will  occur  within  the  logical  framework  of  events  already  defined; 
others  will  require  separate,  new  event  definitions.  The  flank  guard 
detection  (item  1,  above),  for  example,  will  be  based  on  detection 
logic  contained  in  Events  Nos.  503,  504,  and  505,  and  will  be  based 
on  the  geographic  proximity  of  the  enemy  unit(s)  to  the  moving  column. 

Sensor  detections  will  always  be  associated  with  discrete  time 
occurrences  and  will  involve  one  or  more  units  of  the  opposing  side. 

Such  detections  will  always  trigger  Events  No.  450,  which  will  simulate 
the  processing  of  received  intelligence.  This  event  is  described 
below  in  paragraph  H.3.2. 


The  basic  simulation  rule  to  be  used  in  Event  No.  540  is  that 
all  sensor  detections  involving  units  already  in  contact  will  be  ignored. 
Even  though  sensor  detections  may  arise  involving  enemy  u'nit(s)  that 
are  included  in  a  battle  array,  the  logical  structure  of  Event  No.  540 
will  ignore  the  detection  whenever  it  has  been  determined  that  the 
unit(s)  are  engaged.  In  this  manner  the  model  will  generate  contact 
intelligence  about  all  opposing  units  being  engaged  and  sensor  detec¬ 
tions  about  opposing  units  not  in  active  combat. 

H.3.1  Contact  Intelligence 

The  development  of  intelligence  about  opposing  units  that  are 
engaged  in  combat  will  be  based  on  the  assumption  that  units  in  combat 
learn  more  about  the  enemy  the  longer  they  are  engaged.  Accordingly, 
the  collection  and  processing  of  contact  intelligence  will  be  simulated 
by  logic  contained  in  Event  No.  508  (the  basic  engagement  event).  The 
logic  will  provide  for  the  updating  of  the  SOK  indices  and  status  flags 
in  the  ENSIT  records  of  all  units  identified  as  being  in  the  battle 
array  of  the  engagement.  The  SOK  values  in  all  categories  of  ENSIT 
data  -  covering  the  Blue  perceptions  of  Red  units  and  the  Red  percep¬ 
tions  of  Blue  units  -  will  be  governed  by  the  amount  of  time  (actually 
the  number  of  15-minute  engagement  phases)  the  individual  units  have 
been  in  the  battle  array.  At  the  moment  an  individual  unit  first  joins 
the  battle  array,  the  SOK  values  in  its  ENSIT  record  will  be  set  accord¬ 
ing  to  an  internally-stored  schedule  of  "first  contact"  perceptions. 
Thereafter,  the  values  will  increase  as  a  function  of  the  number  of 
phases  of  the  engagement  that  have  elapsed.  In  this  manner,  the  up¬ 
dating  of  the  ENSIT  data  for  the  involved  units  will  be  the  sole  mech¬ 
anism  for  contact  intelligence.  No  explicit  events  other  than  the 
basic  engagement  event  will  be  involved. 


Contact  intelligence  (as  well  as  processes  sensor  detections) 
will  be  reported  to  the  Division  Staff  through  the  event-triggered 
Class  4  messages  No.  459  (Initial  Enemy  Contact)  and  No.  460  (Unit 
Progress  Report)  as  well  as  through  the  time/query-triggered  messages 
No.  465  (Bde/Bn  Situation  Report)  and  No.  441  (Bde  Intelligence  Sum¬ 
mary).  The  corresponding  report-related  Class  5  progenitor  events  are 
Nos.  559,  560,  565,  and  541.  The  first  two  will  be  triggered  by  the 
basic  engagement  event;  the  last  two  will  be  triggered  according  to 
the  reporting  time  SOP.  It  should  be  noted  that  the  first  three  staff 
inputs  are  sent  to  the  G3  and  only  the  last  one  to  G2.  But  all  reports 
contain  intelligence  about  enemy  units  stemming  in  part  from  the  con¬ 
tact  intelligence  mechanism.  The  reports  will  be  generated  (at  pro¬ 
genitor  event  time)  by  routines  like  that  described  on  page  H-9,  there¬ 
by  varying  the  states  of  knowledge  held  by  the  addressees  according 
to  the  SOK  values  in  the  ENSIT  records. 


H.3.2  Sensor  Detections 


As  stated  previously,  sensor  detections  differ  from  contact 
intelligence  in  that  the  former  will  always  involve  explicit  simulated 
events  associated  with  the  detection  and  processing  of  intelligence 
about  enemy  units.  Where  as  contact  intelligence  is  garnered  only  for 
opposing  units  actively  engaged  and  only  during  periods  of  time  when 
the  units  are  in  actual  contact,  sensor  detections  represent  the  con¬ 
tinuous  influx  of  intelligence  from  various  battlefield  sensor  systems. 

All  sensor  detections  trigger  the  battle-related  Class  5  event 
No.  540  (Intelligence  Received  Event).  The  distinction  between  contact 
intelligence  and  sensor  detections  becomes  important  on  the  model 
because  ENS IT  records  in  the  perceived  data  bases  should  not  be  sub¬ 
jected  simultaneously  to  the  contact  intelligence  mechanism  described 
above  and  the  sensor  detection  logic  of  Event  No.  540.  Accordingly, 
the  logic  of  the  intelligence  received  event  will  always  discard  all 
detections  if  they  refer  to  units  that  are  already  in  contact.  This 
wi 1 1  provide  assurance  that  individual  ENS IT  records  will  be  updated 
either  by  the  contact  intelligence  mechanism  or  as  a  result  of  the 
receipt  of  a  sensor  detection,  but  never  both  simultaneously. 

The  event  thread  chart  for  Event  No.  540  is  shown  in  Figure 
H- 2  as  well  as  in  Chart  No.  140  in  Design  Note  J.  The  defined  battle- 
related  Class  5  events  that  trigger  Event  No.  540  have  not  yet  been 
identified,  but  they  will  consist  of  the  following  five  different  kinds 
of  detections  or  intelligence  sources,  as  shown  in  the  chart: 

•  Detection  by  in-place  sensors 

•  Detection  by  cued  sensors 

•  Intelligence  from  an  unimpeachable  source 

•  Detection  by  agents/LRRPs 

•  Assessment  of  damage  from  conventional  or  nuclear  weapons. 
(Events  No.  538  and  539). 

The  follow-on  events  from  Event  No.  540  depend  on  the  nature  and  the 
resulting  S0K  values  emerging  from  the  intelligence  received.  One  or 
more  of  the  following  six  events  could  be  triggered  by  the  receipt  of 
a  sensor  detection: 

•  Event  No.  519  Enemy  Target  Attacked 

•  Event  No.  525  Preparation  of  Target  (Intelligence)  - 
to  be  sent  to  FSE. 

•  Event  No.  543  Preparation  of  Intelligence  Spot  Report  - 
to  be  sent  to  G2. 
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Event  Thread  Chart  Defining  Events  538,  539 ,  sTO,  Intelligence 
Received  Event. 


•  Event  No.  544  Preparation  of  Combat  Intelligence  Report 
to  be  sent  to  62. 

•  Event  No.  545  Preparation  of  Post  Strike  Damage  Report  - 
to  be  sent  to  G2. 

•  Event  No.  566  Preparation  of  Air  Defense  Alert  -  to  be 
sent  to  G3. 

It  should  be  noted  that  the  agency  or  unit  in  the  BOG  that  receives 
and  processes  the  sensor  detection  may  be  ASAC,  DIVARTY,  or  the  ADA 
Bn,  or  the  Red  equivalents.  The  first  and  second  follow-on  events 
above  arise  because  the  acquisition  and  attack  of  enemy  targets  by 
means  of  G2  artillery  or  other  attack  modes  is  an  important  part  of 
the  general  intelligence  gathering  process,  one  which  ordinarily  will 
not  involve  the  Division  Staff.  Similarly,  the  last  follow-on  event 
will  arise  when  the  ADA  sensors  detect  imminent  air  attack  by  the 
opposing  force. 

All  sensor  detections  triggering  Event  No.  540  will  make  re¬ 
ference  to  one  or  more  specific  enemy  unit  entries  on  the  combined 
data  base.  The  basic  logic  of  the  event  will  be  as  follows: 

t  If  the  enemy  units  are  already  in  contact,  discard  the 
detection. 

•  Update  the  ENSIT  records  of  the  units  involved.  If  the 
state  of  knowledge  about  the  units  has  not  improved  (i.e. 
SOK  values  have  not  increased),  update  only  the  time  of 
detection. 

•  Test  the  ENSIT  records  of  the  units  to  see  if  this  re¬ 
presents  a  newly  detected  target  for  the  general  target 
list  (Intelligence).  If  so,  trigger  Event  No.  525  and 
then  execute  attack  decision  logic  to  determine  if  tar¬ 
get  for  G2  fires.  If  so,  trigger  Event  No.  519. 

•  Test  the  ENSIT  records  of  the  units  to  see  if  an  Intel 
Spot  Report  is  warranted.  If  so,  trigger  Event  No.  543. 

•  Test  the  ENSIT  records  of  the  ufiits  to  see  if  a  Combat 
Intel  Report  is  warranted.  If  so,  trigger  Event  No.  544. 

•  If  the  sensor  detection  stems  from  cued  damage  assessment 
events,  trigger  Event  545. 

t  If  the  sensor  detection  stems  from  ADA  sensors,  trigger 
Event  No.  566. 

As  a  consequence  of  this  logic,  the  ENSIT  records  of  all  units 
not  in  contact  will  reflect  the  growth  of  the  state  of  knowledge  held 
by  the  opposing  sides.  All  unit  entries  will  be  flagged  if  they  have 
become  target  list  (Intelligence)  entries;  all  unit  entries  will  be 
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flagged  if  they  have  become  target  list  (artillery)  entries.  The  flag 
variables  and  SOK  values  held  in  the  ENS IT  records  provide  the  basis 
for  time/query-triggered  reports  to  the  Division  Staff  such  as  the 
following: 

•  Event  No.  516  Preparation  of  Target  List  (Arty)  to  be 
sent  to  FSE. 

•  Event  No.  541  Preparation  of  Bde  Intelligence  Summary 
to  be  sent  to  G2. 

•  Event  No.  546  Preparation  of  Estimates  of  Enemy  Strength 
to  be  sent  to  G2. 

•  Event  No.  547  Preparation  of  Full  Target  List  (Intel) 
to  be  sent  to  G2. 

•  Event  No.  562  Preparation  of  Enemy  Electronic  Order  of 
Battle  -  to  be  sent  to  G3. 

•  Event  No.  565  Preparation  of  the  Bde/Bn  Situation  Report 
to  be  sent  to  G3. 

It  should  be  made  clear  that  these  reports  have  not  direct  event  thread 
relationship  with  Event  No.  540,  but  that  they  do  access  the  ENSIT 
records  of  the  perceived  data  bases  which  will  be  continually  modified 
and  updated  by  means  of  Event  No.  540  as  well  as  of  the  basic  engagement 
Event  No.  508. 
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DESIGN  NOTE  I 


GENERAL  DISCUSSION  OF  CLASS  I  EVENTS  AND 
CORRESPONDING  STAFF  ACTION  PROCEDURES  USED  IN  LIVE  MODULES 

I. I  INTRODUCTION 

Class  1  events  represent  the  action-handling  steps  performed 
by  a  staff  section  in  completing  a  required  staff  action.  Class  1 
events  have  meaning  only  for  those  staff  sections  that  are  simulated 
modules.  As  stated  in  paragraph  4. 1.2.1,  staff  actions  executed  by 
populated  modules  will  be  acknowledged  by  the  model  only  throuqh  the 
interface  events  (staff  outputs)  stemming  from  the  actions;  the  sim¬ 
ulator  will  not  record  the  occurrence  of  individual  action  steps  nor 
measure  how  well  the  players  conform  to  the  correct  action  procedures. 
Such  measures  of  player  performance  will  be  handled  under  the  live 
staff  instrumentation  techniques  discussed  in  Section  5.2.2.  The  re¬ 
sults  of  faulty  procedures,  if  any,  carried  out  by  human  players  will 
be  reflected  only  by  adverse  battle  outcomes  or  by  corrective  coordin¬ 
ation  exchanges  coming  from  other  staff  sections. 

Under  most  configurations  of  play,  some  staff  modules  will  be 
simulated  and  others  will  be  populated  with  human  players.  In  the 
simulated  modules,  the  action  steps  in  each  staff  action  will  con¬ 
sist  of,  and  be  represented  by,  a  thread  of  Class  1  events.  The  num¬ 
ber  of  simulated  action  steps  between  the  trigger  and  the  termin¬ 
ator^)  will  depend  on  the  individual  action  SOPs  and  on  the  level  of 
procedural  detail  used  in  the  various  actions. 

In  accordance  with  the  event  numbering  convention  adopted  for 
the  model,  Class  1  events  are  numbered  from  100  to  199.  The  event 
numbers  and  definitions  of  the  Class  1  triggers  and  terminators  for 
all  staff  actions  are  shown  in  Table  1-1.  It  can  be  seen  in  the 
table  that  the  triggers  consist  of  Event  Nos.  100  through  112  and  the 
terminators  are  Event  Nos.  189  through  199,  but  that  intermediate  ac¬ 
tion  steps  have  not  yet  been  defined. 

It  should  be  noted,  furthermore,  that  Class  1  events  have  no 
direct  relationship  with  individual  tactical  information  messages. 
Their  event  numbers  do  not  conform  in  any  way  to  the  rule  of  embedded 
message  numbers. 


This  design  note  addresses  the  Class  1  action  steps  not  yet 
defined  as  well  as  the  corresponding  staff  action  procedures  to  be 
developed  for  human  players  in  live  modules.  These  aspects  of  the 
basic  design  have  given  rise  to  two  fundamental  design  problems  suf¬ 
ficiently  critical  to  warrant  additional  design  effort.  The  problems 
may  be  stated  as  follows: 


Table  1-1.  Class  1  Events. 


Event  Number  Definition  of  the  Event 

Internal 
Tri  qqers 


100 

101 

102 

103 

104 

105 

106 

107 

108 

109 

110 
111 
112 


Clock  indicates  that  is  is  tine  to  initiate  staff  action. 

Receives  a  tactical  information  message  from  BOG  or  higher  HQ. 
Receives  a  retransmitted  copy  of  input  to  another  section. 

Receives  an  info  copy  of  output  by  another  section. 

Receives  a  query  from  another  section. 

Receives  a  request  for  concurrence2  from  another  section. 

Receives  a  request  for  consideration3  from  another  section. 
Receives  a  concurring  response  to  a  request  for  concurrence. 
Receives  a  non-concurring  response  to  a  request  for  concurrence. 
Receives  an  info  copy  of  a  request  frag  order. 

Receives  a  non-concurring  response  to  a  request  for  consideration. 
Receives  a  response  to  its  query  to  another  section. 

Receives  information  f-om  another  section. 


Action 

Steps 

(Not  yet  defined. ) 


Terminators 

189  Sends  to  selected  staff  elements. 

190  Issues  frag  order  or  warning  order. 

191  Initiates  query1 

192  Initiates  a  request  for  concurrence2. 

193  Initiates  a  request  for  consideration3. 

194  Initiates  a  report  for  higher  headquarters. 

195  Aggregates  its  information  on  file  for  a  response. 

196  Issues  a  concurring  response  to  a  request  for  concurrence. 

197  Issues  a  non-concurring  response  to  a  request  for  concurrence. 

198  Issues  a  non-concurring  response  to  a  request. 

199  Retransmits  copies  of  its  input. 


For  all  staff  modules  except  Blue  CG,  queries  will  be  automatically 
separated  into  staff  queries  or  queries  to  subordinate  units.  The 
Blue  CG  module  will  have  the  selectable  option  between  staff  queries 
or  queries  to  subordinate  units. 

2 

A  request  for  concurrence  is  based  on  a  frag  order  under  initiator's 
purview. 

3 

A  request  for  consideration  is  based  on  a  frag. order  under  recipient  s 

purview. _ _ _ 
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•  How  can  the  logic  of  the  Class  1  action  steps  be  made 
to  reflect  simulated  staff  actions  in  simulated  modules 
in  response  to  vari ations  in  the  way  human  players  in 
populated  modules  carry  out  their  staff  procedures? 

•  How  should  the  staff  procedures  prescribed  for  live 
modules  be  written  so  that  they  emphasize  the  research 
objectives  of  the  investigators  and  at  the  same  time 
play  down  the  more  routine  aspects  of  the  staff  actions? 

The  design  note  begins  by  outlining  the  general  method  to  be  used  in 
identifying  the  elementary  operations  involved  in  the  action  steps 
and  in  finding  those  Class  1  events  which  must  invoke  command  and  con¬ 
trol  decision  logic  or  else  controller  intervention.  The  discussion 
continues  by  showing  that  the  first  design  problem  above  arises  be¬ 
cause  the  simulated  staff  modules,  as  well  as  the  battle  outcome 
generator,  must  reflect  the  results  of  faulty  actions  performed  by 
the  teams  of  players  in  live  modules.  The  second  design  problem 
is  then  explained.  The  model  must  allow  the  investiqators/ 
control ler(s )  to  inject  altered  or  faulty  staff  actions  in  simulated 
staff  modules  in  order  that  they  may  observe  in  the  live  module 
responses  reflecting  particular  research  objectives.  The  annex  con¬ 
cludes  with  a  recommended  program  for  completing  the  design  effort. 

1.2  THE  CONCEPT  OF  CLASS  1  EVENT  THREADS 

The  general  method  to  be  used  in  formulating  the  remaining 
Class  1  events  (and  the  corresponding  staff  action  procedures  for 
live  modules)  is  outlined  here  by  developing  and  illustrating  the 
basic  event  threads  and  procedures  for  two  different  tactical  in¬ 
formation  input  messages.  The  examples,  covering  the  staff  process¬ 
ing  of  two  separate  staff  inputs  by  different  staff  sections,  are  as 
follows: 

•  G2  processing  of  an  incoming  Intelligence  Soot  Report 
(Event  No.  443). 

§  G3  processing  of  an  incoming  Briqade/Battalion  Situa¬ 
tion  Report  (Event  No.  465). 

In  these  examples,  as  well  as  in  all  staff  procedures  to  be  used  in 
the  model,  it  should  be  understood  that  the  Class  1  event  threads 
providing  the  simulated  staff  processing  parallel  the  action  steps 
ordinarily  performed  by  a  well  trained  staff  module  with  respect  to 
the  decision  alternatives  addressed  and  the  amount  of  time  taken  to 
complete  the  action  steps.  The  processing  event  threads  should 
ordinarily  lead  to  a  division  staff  response  that  represents  the  cor¬ 
rect  decision  choice  in  a  reasonable  amount  of  time  under  the  exist¬ 
ing  circumstances  of  the  tactical  picture  as  seen  by  staff  section 
and  of  the  workload  carried  by  the  section.  At  the  same  time  the 
structure  of  the  threads  must  be  sufficiently  flexible  to  accommodate 
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incorrect  responses  generated  by  populated  modules  or  variant  responses 
injected  by  the  investigators/control lers  in  order  to  emphasize  par¬ 
ticular  research  objectives.  The  requirement  for  handling  incorrect 
staff  actions  performed  by  live  players  is  developed  further  in 
Paragraph  1.3.1.  The  question  of  the  how  to  specify  the  action  SOPs 
for  players  so  that  the  model  as  a  whole  will  reflect  desired  objec¬ 
tives  in  behavioral  research  is  discussed  in  Paragraph  1.3.2. 

1.2.1  Intermediate  Action  Steps 

The  processing  event  threads  for  the  two  examples  should  re¬ 
flect  the  normal  staff  procedures  executed  (1)  by  the  (simulated) 
Intelligence  Staff  Section  when  it  receives  an  Intelligence  Spot 
Report  and  (2)  by  the  (simulated)  Operations  Staff  Section  when  it 
receives  a  Brigade/Battal ion  Situation  Report.  The  proposed  struc¬ 
ture  of  the  G2  processing  is  shown  in  Figure  I - 1 ;  that  of  the  G3  pro¬ 
cessing  is  shown  in  Figure  1-2. 

It  is  apparent  from  the  two  figures  that  the  two  staff  inputs 
will  be  processed  under  the  same  general  procedural  framework.  Both 
event  threads  are  started  or  triggered  by  the  Class  1  Event  No.  101  - 
the  Receipt  of  the  Tactical  Information  Message.  Both  threads  may  be 
terminated  by  one  or  more  of  the  terminating  Class  1  Events  Nos.  190, 
191,  192,  193,  and  199.  These  events  have  already  been  defined  in 

Table  1-1  (as  well  as  in  Annex  J). 

The  tentative  thread  charts  also  contain  four  intermediate 
Class  1  events  whose  event  numbers  and  basic  definitions  are  tenta¬ 
tive  and  not  yet  fully  developed.  These  are  as  follows: 

•  Event  No.  120  -  Filing  and  Sitmap  Update 

•  Event  Mo.  130  -  External  Distribution  Routina 

•  Event.  No.  170  -  Analysis  of  G2  Alternatives 

•  Event  No.  180  -  Anlaysis  of  G3  Alternatives. 

The  common  procedural  framework  of  the  two  threads  is  further  re¬ 
flected  by  the  use  in  both  threads  of  the  first  two  of  these  inter¬ 

mediate  events.  In  either  procedure,  the  first  action  step  (Event 
Mo.  120)  following  the  receipt  of  the  staff  input  consists  of  the 
section  journal  entry,  the  filing  of  the  report  copies  in  various 
section  files,  and  the  posting  of  tote  entries  and/or  situation  map 
entries,  depending  on  the  nature  and  content  of  the  input  message. 

The  second  action  step  (Event  No.  130)  is  the  determination  of  the 
external  routing,  if  any,  for  retransmission  copies  of  the  staff  in¬ 
put.  The  simulated  staff  section  must  make  the  decision  as  to  what 
other  staff  sections--or  even  higher  headquarters--should  be  sent 
copies.  The  logic  of  this  event  will  trigger  Event  No.  199  for  each 
addressee  selected. 
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Figure  1-1 .  Tentative  Event  Thread  Chart  for  G2  Processing  of  an 
Incoming  Intelligence  Spot  Report. 


Tentative  (vent  Thread  Chart  for  G3  Processing  of  an 
Incoming  Hrigade/Bflttal ion  Situation  Report. 


The  third  action  step  in  the  threads  (Event  ,Jo.  170  in  F inure 
1-1  or  Event  No.  180  in  Figure  1-2)  is  the  fundamental  decision  event 
associated  with  the  staff  input.  The  simulated  section  must  determine 
what  action,  if  any,  is  required  as  the  correct  response  to  the  input 
it  has  received.  Is  the  t.  cJcal  information  content  of  the  report 
such  that  no  further  action  is  indicated  at  this  time?  If  action  is 
required,  is  more  definitive  information  either  from  other  staff  ele¬ 
ments  or  from  subordinate  field  units  needed  before  the  appropriate 
frag  orders  can  be  written?  Is  the  indicated  action  of  sufficient 
importance  or  of  such  a  nature  that  the  Command  Groun  must  concur  or 
corps  guidance  must  be  requested?  Finally,  does  the  required  action 
call  for  one  or  more  frag  orders  issued  by  this  staff  section  or  the 
request  for  consideration  of  action  by  other  sections? 

It  shculd  be  made  clear  about  the  Class  1  event  threads  that 
the  simulation  of  staff  action  steps  will  not  involve  the  explicit 
representati on  of  printed  tactical  '-essaaes,  >'ea!  situation  -aps, 
tote  board  charts,  journals,  or  actual  staff  --ate^ials.  The  realistic 
dynamic  portrayal  of  staff  processing  will  be  developed  in  the  computer 
by  means  of  the  timing  and  logic  of  the  Class  I  events.  The  triaaer 
of  the  two  sample  threads  (in  both  cases.  Event  No.  101),  ■for  example, 
will  simulate  the  receipt  of  the  staff  input  si-ply  t  /  delaying  the 
onset  of  the  first  action  step  (Event  No.  120)  for  a  period  of  simu¬ 
lated  time  equivalent  to  the  average  tire  the  radio  telephone  operator 
(RTO)  would  take  to  copy  the  message.  Similarly,  the  Filina  and  Sit- 
map  Update  step  will  be  simulated  by  injecting  a  further  delay  in 
simulated  time,  in  this  case,  a  delay  which  is  a  function  of  the  type 
of  staff  input,  the  relative  size  of  the  channes  in  the  tactical  pic¬ 
ture  it  deals  with,  and  the  current  workload  impinging  on  the  staff 
section. 

The  subsequent  action  steps  shown  in  the  sample  threads  in¬ 
volve  decision  logic.  In  each  thread  the  simulated  section  must  make 
certain  choices  or  selections  pertinent  to  the  command  and  control  of 
the  division-level  combat.  The  logic  in  these  events  will  be  based 
on  ENSIT  and  ERENSIT  data  stored  in  the  perceived  data  bases  because 
the  simulated  staff  section  is  presumed  to  hav£  on  file  or  in  staff 
displays  all  the  relevant  tactical  information  within  its  purview. 

While  the  algorithms  for  making  decision  choices  have  not  yet  been 
developed,  two  basic  design  principles  have  been  identified  for  their 
development.  These  principles  are: 

t  Simulated  decision-makina  will  be  based  on  "decision 

tables"  in  which  the  alternatives  will  be  examined  and 
eliminated  in  a  linear  process. 

•  The  algorithms  will  minimize  insofar  as  possible  the 

instances  where  controller  intervention  (release  events) 
will  be  required. 


utew***'*-  * 


The  terminator  events  in  the  sample  threads  (nos.  190,  191, 

192,  193,  and  199)  will  simulate  the  issuance  of  frag  orders,  etc., 
simply  by  injecting  further  delays  in  simulated  time  to  account  for 
the  amount  of  time  the  simulated  section  would  take  to  compose, 
draft,  and  transcribe  the  appropriate  staff  outputs. 

1.2.2  Processing  of  an  Intel! iqence  Spot  Report 

The  parallelism  between  the  Class  1  event  thread  in  Figure 
1-1  and  the  staff  procedure  to  be  executed  by  a  populated  G2  staff 
Module  is  illustrated  in  Table  1-2.  The  table  shows  in  separate 
columns  the  processing  of  an  incoming  Intelligence  Spot  Reoort  that 
will  occur  in  simulation  when  the  G2  module  is  simulated  juxtaposed 
with  the  staff  procedure  for  the  same  report  when  the  G2  module  is 
played  by  human  players. 

1.2.3  Processing  of  a  Brigade/Battalion  Situa t ion  Report 

The  parallelism  between  the  Class  1  event  thread  in  Fiqure 
1-2  and  the  staff  procedure  to  be  executed  by  a  populated  G3  Staff 
Module  is  illustrated  in  Table  1-3.  The  talbe  shows  the  same  juxta¬ 
position  of  the  simulated  and  live  module  Drocedures  as  that  given 
in  Table  I - 3 . 

1.3  DESIGN  PROBLEMS 

The  top-down  design  of  the  Division  Level  Battle  Simulation 
is  essentially  complete  with  the  addressal  of  Class  1  events  for  sim¬ 
ulated  staff  modules.  However,  as  stated  above,  during  the  preliminary 
definition  of  the  Class  1  action  steps  for  simulated  staff  modules, 

SAI  uncovered  two  design  problems  which  are  sufficiently  critical  to 
warrant  additional  design  effort. 

The  design  objective  was  to  construct  the  simulated  staff 
modules  in  such  a  manner  that  the  modules  would  initiate  outputs  or 
respond  to  inputs  in  a  "perfect"  manner,  i.e.,  based  upon  those  staff 
actions  required  of  a  particular  staff  section  within  doctrinal  and 
field  manuals.  Underlying  the  design  philosophy  was  the  thought  that 
this  concept  would  allow  ARI  investiqators  to  isolate  (or  insulate) 
populated  staff  modules  in  order  to  achieve  maximum  control  of  the 
experiment.  However,  as  the  design  took  form  and  substance  it  became 
apparent  that  although  our  design  achieved  the  level  of  experimental 
control  desired  it  would  not  truly  reflect  a  variable  level  of  com¬ 
mand  and  control  by  populated  staff  modules. 

The  second  design  problem  concerns  the  level  of  detail  required 
within  a  populated  module.  Larqe  amounts  of  data  are  required  by 
division  staff  sections  to  effect  decisions.  Obviously,  the  computer 
has  no  problem  organizing  and  recalling  the  data.  Just  as  obviously, 
it  became  clear  that  populated  modules  would  be  spendinq  an  inordinate 
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Table  1-2 


PROCESSING  OE  AN  INTELLIGENCE  SPOT  REPORT 


Class  1  Events  in  a  Simulated  G2 
Staff  Module. _ 

Event  101  -  Receipt  of  an  Intelli¬ 
gence  Spot  Report.  This  event  will 
occur  3  to  10  minutes  after  Event 
No.  443  (Intel  Spot  Report). 

Event  120  -  Filing  and  Sitmap  Update. 
This  event  will  occur  10  to  15  minutes 
after  Event  No.  101  to  account  for 
journal  entry,  journal  filing,  pos¬ 
sible  posting  on  the  Significant 
Events  Chart  and/or  updating  the 
ENSIT  map. 


Event  1_30  -  External  Distribution 
Routing.  This  event  will  occur  1  to 
3  minutes  after  Event  No.  120  to  ac¬ 
count  for  G2  determining  the  exter¬ 
nal  routing  for  retransmission  info 
copies.  The  event  logic  will  be  as 
fol 1 ows : 

•  If  report  signals  possible  tar¬ 
get  acquisition,  it  is  routed  to 
FSE  and  G3. 

•  If  report  suggests  significant 
ENSIT  changes,  it  is  routed  to 
CG  and  G3 

Each  addressee  selected  triggers  a 
separate  Event  No.  199  (Rxmit). 


Staff  Procedure  in  a  Live  G2 
Staff  Module _  __  _ _ 

When  the  teletype  printer  finishes 
printing  the  Intel  Spot  Report, 
the  printer  text  is  torn  off. 


The  incoming  spot  report  is  log¬ 
ged  into  the  G2  journal.  The 
internal  processing  is  then  de¬ 
termined  by  the  subject  matter  of 
the  report.  If  the  report  sig¬ 
nals  a  significant  combat  event, 
this  event  is  posted  on  the  Sig¬ 
nificant  Events  Chart;  if  it  sig¬ 
nals  a  significant  cnange  in  the 
enemy  situation,  appropriate 
changes  are  posted  on  the  ENSIT 
map.  Before  further  action  is 
considered,  the  original  report 
copy  is  filed  in  the  G2  journal 
file. 

The  G2  determines  the  external 
routing  of  retransmission  copies 
based  on  the  subject  matter  of 
the  report. 

•  If  the  report  does  not  sig¬ 
nal  a  possible  target  acqui¬ 
sition  or  a  niassi  ve  ENSIT 
change,  no  info  copies  are 
retransmi tted. 

•  If  the  report  signals  a  pos¬ 
sible  target  acquisition, 
info  copies  are  routed  to 
the  Fire  Support  Element 
and  to  G3  Operations. 

•  If  the  report  signals  a  signif¬ 
icant  ENSIT  change,  info  copies 
are  routed  to  the  Command 
Group  and  to  G3  Operations. 


PROCESSING  OF  AN  INTELLIGENCE  SPOT  REPORT  (CONT.) 


Class  1  Events  in  a  Simulated  G2 
Staff  Module. _ 

Event  170  -  Analysis  of  G2  Alterna¬ 
tives.  This  event  will  occur  3  to 
30  minutes  after  Event  No.  130  to 
reflect  the  time  the  G2  takes  to 
determine  the  response  to  the  spot 
report.  The  event  logic  will  be  as 
fol 1 ows : 

•  If  no  further  action  required,  no 
follow-on  events  are  triggered. 

•  If  the  required  action  is  a  frag 
order  (Intel),  Event  190  is 

tri ggered. 

•  If  a  staff  query  or  query  to  field 
required.  Event  191  is  triggered. 

•  If  a  request  for  consideration  is 
required,  Event  192  is  triggered. 

•  If  a  request  for  concurrence  is 
required.  Event  193  is  triggered. 


Processing  is  complete  when  the  latest 
occurrence  among  Event  Nos.  170,  190, 
191,  192,  or  193  takes  place. 


Staff  Procedure  in  a  Live  G2 
Staff  Module _ 

The  G2  analyzes  the  subject  of 
the  report  in  the  framework  of 
the  ENSIT  information  his  sec¬ 
tion  has  on  file.  He  then  de¬ 
termines  what  action,  if  any, 
is  required. 

•  If  no  further  action  required, 
the  procedure  is  completed. 

•  If  further  intelligence  data 
must  be  collected,  a  frag 
order  (Intel)  is  issued  re¬ 
directing  the  data  collection 
resources . 

•  If  an  update  on  status  of 
ACS  troops  indicated,  a 
query  is  initiated  to  G3. 

•  If  a  reconnaissance-in-force 
is  the  requi red  action,  a 
request  for  consideration 
(frag  order  (OPS))  is  ini¬ 
tiated  to  G3. 

•  If  reconnaissance  by  air 
cavalry  is  required,  a  re¬ 
quest  for  concurrence  on  the 
frag  order  is  sent  to  G3. 

The  staff  action  is  complete  when 
the  last  of  the  follow-on  staff 
outputs  has  been  "transmitted" 
to  the  controller. 


Table  1-3 


PROCESSING  OF  A  BRIGADE/BATTALION  SITUATION  REPORT 

Class  1  Events  in  a  Simulated  63  Staff  Procedure  in  a  Live  G3 

Staff  Module _ Staff  Module _ 

Event  101  -  Receipt  of  the  Bde/Bn  When  the  teletype  printer  fin- 

Situation  Report.  This  event  will  ishes  printing  the  Situation 

occur  6  to  15  minutes  after  Event  Report,  the  printed  text  is 

No.  465  (Bde/Bn  Sitrep).  torn  off. 


Event  120  -  Filing  and  Sitmap  Update 
This  event  will  occur  10  to  15  min¬ 
utes  after  Event  No.  101  to  account 
for  journal  entry,  journal  filing, 
possible  posting  on  the  Operations 
Sitmap  and/or  Unit  Status  Board. 


Event  130  -  External  Distribution 
Routing.  This  event  will  occur  1  to 
3  minutes  after  Event  No.  120  to  re¬ 
flect  the  time  G3  takes  to  authorize 
the  retransmission  of  info  copies  to 
selected  addressees.  Each  addressee 
selected  triggers  a  separate  Event 
No.  199  (Rxmit). 


The  incoming  situation  report  is 
logged  into  the  Operations  jour¬ 
nal.  The  internal  processing  of 
the  report  is  then  modified  ac¬ 
cording  to  the  salient  ENSIT  and 
FRENSIT  aspects  of  the  reported 
situation.  If  subordinate  units 
of  the  report  initiator  have  re¬ 
located  their  forward  elements, 
headquarters,  or  front  line  trace, 
these  changes  are  posted  on  the 
Operations  Sitmap;  if  the  report 
reflects  significant  casualty 
losses  for  the  subordinate  units, 
these  are  posted  as  decrements  on 
the  G3  Unit  Status  Board.  The 
situation  report  is  then  repro¬ 
duced,  as  required,  and  the  ori¬ 
ginal  filed  for  use  in  prepara¬ 
tion  of  the  Division  Sitrep  at 
a  later  time. 

The  G3  determines  the  external 
routing  of  retransmission  info 
copies.  'Ordinarily,  copies  of 
the  Situation  Report  are  routed 
to  all  other  staff  elements  ex¬ 
cept  the  Command  Group.  If  the 
report  signals  or  completes  the 
signal  for  either  an  exploitable 
enemy  weakness,  an  impen-d'ing  dis¬ 
aster  on  the  friendly  forces,  or 
other  significant  circumstance, 
an  info  copy  is  routed  to  the 
Command  Group  also. 


PROCESSING  OF  A  BRIGADE/BATTALION  SITUATION  REPORT  (CONT. 


Class  1  Events  in  a  Simulated  G3 
Staff  Module _ _ _ 

Event  180  -  Analysis  of  G3  Alterna¬ 
tives.  This  event  will  occur  5  to 
23  minutes  after  Event  No.  130  to 
reflect  the  time  the  G3  takes  to 
determine  what  course  of  action,  if 
any,  is  required. 

•  If  no  action  is  required  at  this 
time,  no  follow-on  event  is 

tri ggered. 

•  For  each  frag  order  (OPS)  issued 
as  part  of  the  required  action, 

a  separate  Event  No.  190  is 
tri ggered. 

•  For  each  staff  query  initiated 
as  part  of  the  required  action, 
a  separate  Event  No.  191  is 

tri ggered. 

•  For  each  request  for  concurrence 
initiated  as  part  of  the  required 
action,  a  separate  Event  No.  192 
is  triggered. 

•  For  each  request  for  considera¬ 
tion  initiated  as  part  of  the 
required  action,  a  separate 
Event  No.  193  is  triggered. 

Processing  is  complete  when  the  latest 
occurrence  among  Event  Nos.  180,  190, 
191,  192,  and  193  takes  place. 


Staff  Procedure  in  a  Live  G3 
Staff  Module  _ _ 

The  G3  analyzes  the  situation 
report  in  the  framework  of  the 
existing  situation,  to  include 
the  committed  and  uncommitted 
friendly  forces,  and  future 
operational  objectives.  He  then 
determines  whether  action  is 
required  at  this  time. 

•  If  no  action  is  required  at 
this  time,  the  procedure  is 
completed. 

$  If  action  is  required  and 
i f  the  si tuati on  can  be 
handled  without  further  staff 
coordination,  the  G3  simply 
issues  the  necessary  frag 
order(s)  (OPS). 

•  If  the  situation  requires 
staff  coordination,  the  G3 
initiates  either  queries  or 
requests  to  the  other  cog¬ 
nizant  staff  sections  or  the 
commander  containing  one  or 
more  courses  of  action  he 
proposes . 

The  staff  action  is  complete  when 
the  last  of  the  follow-on  staff 
outputs  is  "transmitted"  to  the 
control  1 er. 
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amount  of  time  posting  situation  maps,  record  keeping,  and  other  sim¬ 
ilar  functions.  It  is  felt  that  this  aspect  of  the  desiqn  would 
cause  boredom  and  decrease  players  interests  in  the  game. 

Both  of  these  problems  are  discussed  in  detail  below. 

1.3.1  Simulation  of  Command  and  Control 


This  problem  is  best  explained  by  recalling  all  five  classes 
of  events  and  their  interactions.  Class  1  events  occur  within  staff 
modules;  Class  2,  3,  and  4  events  occur  at  the  staff  module  bound¬ 
aries;  and  Class  5  events  occur  within  the  Battle  Outcome  Generator. 
The  design  provides  that  these  events  are  to  be  connected  by  event 
threads  which  cause  the  successive  events  to  occur  in  the  prescribed 
logical  sequence.  Within  a  populated  module  the  players  themselves 
carry  out  the  action  steps  and  react  to  or  generate  the  interface 
events.  In  a  simulated  module,  these  threads  must  be  provided  within 
the  simulation.  It  is  conceptually  a  simple  matter  to  close  the 
event  threads  that  are  routed  through  the  simulated  modules  so  that 
they  are  essentially  independent  of  any  other  module,  i.e.,  so  that 
they  are  essentially  insulated  from  perturbations  to  the  information 
flow  that  might  occur  if  a  populated  module  did  not  behave  in  the 
manner  being  simulated  when  the  module  is  not  populated.  If  the 
model  were  designed  in  this  manner,  the  only  abnormal  behavior  of  a 
populated  module  that  would  be  reflected  in  the  simulation  would  be 
failure  to  close  an  event  thread  that  led  through  that  module.  Such 
a  design  would  not  be  responsive  to  the  major  objectives  of  providing 
feedback  to  players  or\  the  results  of  their  actions.  The  simulation 
should  show  the  effect  of  degraded  performance  within  a  live  staff 
module  in  all  of  the  other  command  control  activities  being  simulated. 
This  will  require  very  careful  and  detailed  analysis  of  all  event 
thread  routing  to  insure  that  the  effects  of  incorrect  staff  action 
by  a  live  staff  module  are,  in  fact,  portrayed  as  unforeseen  events 
and  delayed  and/or  degraded  reports  that  would  result.  Examples  of 
such  degraded  performance  by  a  live  G2  module  would  be:  faulty 
tasking  of  sensor  systems  that  would  reduce  the  enemy  information 
available  to  the  command  groups  or  the  G3;  assignment  of  an  intel¬ 
ligence  mission  to  the  cavalry  squadron  without  coordination  with  G3 
which  resulted  in  non-availability  of  the  squadron  for  an  operational 
mission;  or  faulty  tasking  of  sensor  systems  that  denied  important 
target  information  to  the  FSE. 

One  important  facet  of  this  problem  that  cannot  be  overlooked 
is  the  real  world  response  time  to  such  faulty  actions.  For  example, 
faulty  tasking  of  sensors  by  G2  that  resulted  in  degraded  target 
information  for  the  FSE  would  affect  the  ongoing  battle.  Faulty 
sensor  tasking  that  reduced  intelligence  available  to  the  G3  or  the 
command  group  could  affect  the  ongoing  battle,  but  would  even  more 
likely  lead  to  bad  planning  for  tomorrow's  battle.  The  latter  effect 
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is  difficult  to  capture  in  a  4-12  hour  scenario.  Thus,  the  effects 
of  faulty  staff  actions  that  lead  to  degraded  planning  for  future  ac¬ 
tion  may  be  difficult  to  capture  without  implementing  the  faulty  plan. 

1.3.2  Task  Design  for  Interactive  Simulations 

If  the  simulation  is  to  be  a  cost-effective  tool  for  research, 
not  only  must  the  personnel  requirements  be  held  to  a  minimum  in  the 
control  section,  but  the  number  of  players  in  a  live  staff  module  must 
also  be  held  to  a  credible  minimum  and  the  design  must  be  such  that 
the  players  maintain  a  high  degree  of  interest.  One  way  to  approach 
this  goal  is  to  eliminate  some  of  the  low  skill  level,  high  frequency, 
and  hence,  boring  tasks  within  the  staff  module.  An  insight  as  to 
what  this  entails  may  be  gained  by  viewing  the  staff  module  as  a  deci¬ 
sion  node  and  looking  at  the  sequence  of  kinds  of  processes  that  it 
performs. 

Figure  1-3  is  a  representation  of  a  series  of  processes  such 
a  decision  node  carries  out  on  information  flowing  through  the  node. 

At  the  bottom  of  the  figure  is  an  external  information  stream--the 
communications  network--which  the  node  taps  and  to  which  it  contributes. 
Six  progressi vely  more  complex  processing  levels  are  depicted.  The  in¬ 
formation  that  flows  up  from  the  external  stream  must  first  be  re¬ 
ceived,  a  Level  I  or  communications  process.  The  received  information 
in  a  tactical  military  system  is  in  the  for  of  orders  (plans),  sum¬ 
maries,  reports,  queries,  or  requests.  These  must  be  taqged,  sorted, 
recorded  (think  of  the  large  number  of  telephont  :nd  voice  radio  in¬ 
puts),  and  used  to  update  files;  much  of  it  is  a<-0  displayed  on  sit¬ 
uation  maps  or  "totes."  The  composite  of  these  processes  may  be  called 
Level  II  or  message  center  and  filing  processes.  The  Level  II  processes 
produce  a  data  base,  some  part  of  which  is  in  the  for:;:  of  visible  dis¬ 
plays  for  ready  reference.  It  is  pertinent  to  comment  in  passing  that 
the  graphical  representation  of  certain  kinds  of  information  on  a  sit¬ 
uation  map  is  the  substitute  for  the  hill  overlooking  the  battlefield 
and  for  helicopters  when  the  latter  cannot  fly  or  see. 

The  next  four  process  levels  use  the  files  in  successively 
more  complex  ways.  Note  that  they,  too,  update  the  files,  but  these 
updates  are  more  in  the  nature  of  manipulations  on  the  basic  data 
added  by  Level  II.  These  utilization  processes  begin  with  Level  III, 
selective  retrieval  of  information  from  the  files.  At  Level  IV,  such 
data  are  aggregated  by  means  of  a  priori  rule,  which  may  vary  from 
simple  arithmetic  combinations  to  more  sophisticated  rules  of  com-, 
bination  such  as  the  appearance  of  three  or  four  maneuver  battalions 
operating  in  the  same  area  triggers  the  search  for  their  associated 
fire  and  service  support  elements.  The  important  consideration  is 
that  the  rules  for  aggregation  have  been  determined  in  advance  and 
are  stored.  Process  Level  V  also  aggregates  data,  but  the  rules  for 
aggregation  are  devised  by  the  user  in  real  tirne--that  is,  he  hypoth¬ 
esizes,  'through  pattern  recognition,  new  and  higher  level 
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Level  VT 


Figure  1-3.  Process  Levels  in  a  Tactical  Decision-Making  Node. 
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interpretations  of  the  data  beina  presented.  Level  V  produces  what 
is  commonly  called  "perception. 11  At  the  hiqhest  level.  Level  VI, 
data  aggregations  are  compared  and  evaluated,  and  one  or  more  are  se¬ 
lected.  This  last  is  the  culmination  of  the  decision  process. 

Emulating  this  series  of  processes  that  occur  in  a  decision 
node  is  the  design  objective  of  the  Class  1  events  and  their  inter¬ 
connecting  event  threads.  Insofar  as  possible  this  decision  process 
within  simulated  modules  will  be  completed  without  controller  inter¬ 
vention.  This  will  have  the  desired  effect  of  minimizing  the  amount 
of  controllers  required.  On  the  other  hand,  in  populated  modules  the 
goal  is  to  reduce  those  lower  level  tasks  to  a  minimum  (without  losing 
realism)  in  order  to  maintain  player  interest  and  allow  the  ARI  in¬ 
vestigators  to  concentrate  on  the  research  objectives. 

With  this  view  of  a  manual  information  processing  system,  we 
can  gain  some  insights  as  to  what  might  happen  when  we,  in  effect 
shift  the  interface  between  the  staff  module  and  the  outside  world 
from  its  peripheral  communication  nodes  and  move  some  of  the  lower 
level  communication  and  message  center  and  filina  functions  out  of 
the  module  and  into  the  simulation.  We  are  faced  with  the  problem 
of  redefining  the  tasks  to  be  conducted  within  the  staff  module  in 
such  a  way  that  the  node  remains  a  realistic,  credible,  military 
decision-making  environment,  i.e.,  appears  to  the  players  to  be  a 
staff  element  and  not  a  laboratory  for  studying  human  reactions.  The 
problem  is  quite  similar  to  that  faced  by  the  ADP-assisted  system  de¬ 
signer  because  it  amounts  to  shifting  the  interface  between  the  de¬ 
cision  maker  and  the  outside  world. 

1.4  EXPAND  DESIGN  OBJECTIVES 

With  a  clear  understanding  of  the  two  design  problems  as  pre¬ 
sented  above,  SAI  recommends  that  the  design  phase  of  this  effort  be 
expanded  to  allow  us  to  achieve  a  fully  responsive  design,  i.e.,  one 
that  overcomes  these  deficiencies  and  advances  the  state  of  the  art 
of  interactive  battle  simulations. 


DESIGN  NOTE  J 


EVENT  1HREAD  CHARTS 
J.l  EXPLANATION  OF  THE  CHARTS 

This  design  note  contains  the  event  thread  charts  specifying 
the  logical  progenitors  and  followers  of  all  defined  events  in  the 
simulation.  The  index  to  the  charts  is  given  in  Table  J-l.  The 
index  provides  a  general  event  sequence  description,  the  numbered 
events  involved,  and  page  number  for  each  chart. 

The  event  threads  associated  with  a  specific  tactical  infor¬ 
mation  message  are  given  in  a  chart  whose  chart  number  is  the  same 
as  the  basic  reference  number  of  the  message.  The  reference  numbers 
stem  from  Desiqn  Note  A. 

The  event  threads  dealing  with  internal  staff  action  steps 
(Class  1  events),  as  well  as  maneuver  and  engagement  events  (Class  5 
are  given  on  charts  whose  chart  numbers  are  those  above  100.  The 
definitions  of  the  events  in  these  threads  are  as  yet  incomplete. 


Table  J-l.  Index  to  the  Event  Thread  Charts. 


CHART 

NO. 

GENERAL  EVENT  SEQUENCE  SHOWN 

DEFINED  EVENTS  INCLUDED 

CL  1  CL  2  CL  3  CL  4 

CL  5 

PAGE 

NO. 

01 

Query  by  Command  Group 

(104,191) 

201 

301 

501 

J-5 

02 

Nuclear  Release  Request 

(103,194) 

202 

302 

502 

J-6 

030 

Mission  Analysis 

(189) 

203 

J-7 

040 

Commander's  Guidance 

(189) 

204 

J-8 

05 

Commander's  Decision 

(106,193) 

205 

J-9 

10 

Query  by  FSE 

(104,191) 

210 

310 

510 

J-10 

11 D 

Query  to  Corps  on  Frag  Order  (FS) 

311 

511 

J-l  1 

12 

Issuance  of  Frag  Order  (FS) 

(103,190) 

212 

312 

512 

J-l  2 

13 

Immed.  Rqst  to  Corps  for  FS 

1103,193) 

213 

313 

513 

J-l  3 

14 

Prplnnd  Rqst  to  Corps  for  FS 

(103,194) 

214 

314 

514 

J— 1 4 

15 

Arty  Sitrep 

(101 ,199) 

215 

415 

515 

J-15 

16 

Target  List  (Arty) 

(101 ,199) 

216 

416 

516 

J-16 

17 

FU  Fire  Spt  Cap 

(101 ,199) 

217 

417 

517 

J-l  7 

18 

EU  Fire  Spt  Cap 

(101 ,199) 

218 

418 

518 

J-l  8 

19 

Post  Strike  Analysis 

(112,189) 

219 

J-l  9 

20 

Fire  Spt  Annex 

(189) 

220 

J-20 

21 

Staff  Request  by  FSE 

(105,106,192,193) 

221 

J-21 

22 

Staff  Response  by  FSE 

(107,108,110,111  ,195,196,197,198) 

222 

J-22 

23 

Immed.  Rqst  for  FS 

(101 ,199) 

223 

423 

523 

J-23 

23D 

Immed.  Rqst  from  Adj  Div 

423D 

523D 

J- 24 

24 

Prplnnd  Rqst  for  FS 

(101,199) 

224 

424 

524 

J-25 

25 

Target  ( Intel ) 

(101,199) 

225 

425 

525 

J-26 

26 
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DEFINING  EVENTS  189,204 


EVENT  THREAD  CHART  #05 
DEFINING  EVENTS  106,  193,  205 
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EVENT  THREAD  CHART  #12 
DEFINING  EVENTS  103,  190,  212,  312,  512 
ISSUANCE  OF  FRAG  ORDER  (FS) 


RELEASE  EVENT 


EVENT  THREAD  CHART  #14 


EVENT  THREAD  CHART  #15 
FINING  EVENTS  101,  199,  215,  415,  515 


EVENT  THREAD  CHART  #16 
DEFINING  EVENTS  101,  199,  216,  416,  516 
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EVENT  THREAD  CHART  #18 
DEFINING  EVENTS  101,  199,  218,  418,  518 
ENEMY  UNIT  FIRF  SUPPORT  CAPABILITY 


ncludes  CG,  G2,  G3 


EVENT  THREAD  CHART  #  20 
DEFINING  EVENTS  189,  220 
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NOTE:  SM  may  be  G2,  G3,  or  G1-G4. 
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EVENT  THREAD  CHART  #33D 
EFINING  EVENTS  233,  333,  533 


NOTE:  SM  includes  live  modules  among  all  other  sections 
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Tn.Tr.  r/>n DEFINING  EVENTS  189,  236 
INTELLIGENCE  PARAGRAPH  OF  DIVISION  SITUATION  REPORT 


EVENT  THREAD  CHART  # 37D 
DEFINING  EVENTS  189,237 
INTELLIGENCE  ESTIMATE 
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DEFINING  EVENTS  189,  238 
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NOTE:  SM  may  be  FSE,  G3,  or  G1-G4. 
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NOTE:  SM  includes  all  live  staff  modules. 


EVENT  THREAD  CHART  #54 
DEFINING  EVENTS  103,  190,  254,  354,  554 
ISSUANCE  OF  NUCLEAR  WARNING  ORDER 


■COPIE 


EVENT  THREAD  CHART  #56 


RELEASE  EVENT 


EVENT  THREAD  CHART  #  58 
DEFINING  EVENTS  189,  189,  258 
OPERATIONS  ESTIMATE 


nlucdes  all  live  staff  modules. 


EVENT  THREAD  CHART  #  63 
DEFINING  EVENTS  105,  106,  192,  193,  263 


EVENT  THRE 

DEFINING  EVENTS  107,  106, 
STAFF  RESPONSE 


POPULATED 


EVENT  THREAD  CHART  if  71 
FINING  EVENTS  471,  571 


CHART  #  72D 


EVENT  THREAD  CHART  #80 
DEFINING  EVENTS  104,  191,  280,  380,  580 


RELEASE  EVENT 


THREAD  CHART  #84D 


RELEASE  EVENT 


EVENT  THREAD  CHART  #85D 
DEFINING  EVENTS  103,  194,  285,  385,  585 


EVENT  THREAD  CHART  #86D 
DEFINING  EVENTS  103,  194,  286D,  386,  586D 
IMMEDIATE  REQUEST  TO  CORPS  FOR  LOGISTICAL  SUPPORT 


EVENT  THREAD  CHART  #87D 
DEFINING  EVENTS  189,287 
COMBAT  SERVICE  SUPPORT  ESTIMATE 


EVENT  THREAD  CHART  #  88D 
DEFINING  EVENTS  189,  288 
COMBAT  SERVICE  SUPPORT  ANNEX 


EVENT  THREAD  CHART  #89 
DEFINING  EVENTS  105,  106,  192,  193,  289 
STAFF  REQUEST  BY  G1-G4  SECTION 


NOTE:  SM  may  be  FSE,  G2,  or  G3. 


EVENT  THREAD  CHART  #90 

DEFINING  EVENTS  107,  108,  110,  111,  195,  196,  197,  198,  2SO 
STAFF  RESPONSE  BY  G1/G4  SECTION  _ 
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DEFINING  EVENTS  538,  539,  540 
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2  USCG  Academy,  New  London.  ATTN:  Admission 
2  USCG  Academy.  New  London.  ATTN:  Library 

1  USCG  Training  Ctr.  NY.  ATTN:  CO 
1  USCG  Training  Ctr.  NY,  ATTN"  Educ  Svc  Ofc 
1  USCG,  Psychol  Res  Br.  DC.  ATTN  GP  1/62 
1  HO  Mid-Range  Br,  MC  Det,  Quantico.  ATTN  P&S  Div 
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1  US  Marine  Corps  Liaison  Ole,  AMC.  Alexandria,  ATTN  AMCGS  • 

1  USA!  RADOC,  Ft  Monroe.  ATTN  ATRO  FD 
6  USATRADOC.  Ft  Monroe.  ATTN  ATPR  AD 

1  USATRADOC,  Ft  Monroe,  ATTN  ATTS  EA 

t  USA  Forces  Cmd.  Ft  McPherson.  ATTN  library 

2  USA  Aviation  Test  Bd,  Ft  Ruckei,  ATTN  STF0G  PO 

1  USA  Agcy  tor  Aviation  Saf**ly,  I  t  Bucket,  A  IN  Lifwary 
I  USA  Agty  lor  Aviation  Safety.  Ft  Rucker.  ATTN  Educ  Advisor 
1  USA  Aviation  Sch.  Ft  Rucker,  ATTN  PO  Drawer  0 
1  HQUSA  Aviation  Sys  Cnul.  St  Louis,  ATTN:  AMSAV  ZDR 
?  USA  Avialion  Sys  Test  Act  ,  Kdw.nds  AF  B,  ATTN:  SAV  TE  T 
1  USA  Air  Del  S<h.  Ft  Hlis  ATTN  A TSA  TFM 

1  USA  An  Mobility  Rst.l>  &  Dev  Lal>,  Molfett  Fid.  ATTN:  SAVDL  AS 
I  USA  Aviation  Sch.  Res  Trig  Mgt.  Ft  Rucker,  ATTN  ATST  T  RTM 
1  USA  Aviation  Sch,  CO,  Ft  Rucker.  ATTN:  ATST-D  A 
1  HO.  DARCOM.  Alexandria,  ATTN  AMXCD  Tl 
1  HQ.  OARCOM.  Alexandria.  ATTN  CDR 
1  US  Military  Academy,  West  Point.  ATTN:  Serials  Unit 
1  US  Military  Academy.  West  Point.  ATTN:  0*c  of  M.lt  Ldr  .lip 
1  US  Military  Academy.  West  Point.  ATTN  MAOR 
I  USA  Standardization  Gp,  UK,  FPO  NV.  ATTN.  MASE  -  GC 
1  Otc  of  Naval  Rsch.  Arlington.  ATTN  Code  452 

3  Ofc  of  Naval  Rsch.  Arlington,  ATTN:  Code  458 
1  Ofc  of  Naval  Rsch.  Arlington.  ATTN:  Cotie  450 
1  Ofr  of  Naval  Rsch,  Arlington.  ATTN:  Cotie  441 

1  Naval  Aeeospc  Med  Res  Lab.  Pensacola.  ATTN  Acous  Sch  Qiv 
I  Naval  Aerospr  Med  Res  Lab.  Pensacola,  ATTN:  Code  LSI 
I  Naval  Aerospc  Med  Res  Lab.  Pensacola.  ATTN:  Code  L5 
1  Clmd  of  NavPrrs,  ATTN  Pers-OR 
I  NAVAIRSTA.  Norfolk,  ATTN:  Safety  Ctr 
1  Nav  Oceanographic,  DC,  ATTN:  Code  6251,  Charts  &  Tech 
1  Center  of  Naval  Anal.  ATTN:  Doc  Ctr 
1  NavAnSysCom.  ATTN:  AIR  531 3C 
1  Nav  BuMed.  ATTN:  713 
1  NavHelicopteiSubSqua  2,  FPOSF  96601 
1  AFHRL  (FT)  Williams  AFB 
1  AFHRL  (TT)  Lowry  AFB 

1  AFHRL  (AS)  WPAFB.OH 

2  AFHRL  (DOJZ)  Brooks  AFB 

1  AFHRL  (DOJN)  Lackland  AFB 
1  HQUSAF  (INYSD) 

1  HQUSAF (DPXXA) 

1  AFVTG  (RD!  Randolph  AFB 

3  AMRL  (HE)  WPAFB.  OH 

2  AF  Inst  of  Tech,  WPAFB,  OH,  ATTN:  ENE/SL 
1  ATC  (XPTD)  Randolph  AFB 

1  USAF  AeroMed  Lib.  Brooks  AFB  (SUL  4),  ATTN:  DOC  SEC 
1  AFOSR  (NLI,  Arlington 

1  AF  Log  Cmd.  McClellan  AFB,  ATTN:  ALC/DPCRB 

1  Air  Force  Academy,  CO,  ATTN:  Dept  of  Bel  Sen 
5  NavPers  &  Dev  Ctr.  San  Diego 

2  Navy  Med  Neuropsychiatric  Rsch  Unit.  San  D<ego 
1  Njv  Electronic  Lab.  San  Diego.  ATTN  Res  Lab 

1  Nav  TrngCen,  San  Diego.  ATTN:  Code  9000-  Lib 
1  NavPostGraSch.  Monfeiey.  ATTN:  Code  55Aa 
1  NavPostGraSch.  Monterey,  ATTN:  Code  2124 
1  NavTmgEquipCtr,  Orlando,  ATTN  Tech  Lib 
1  US  Dept  of  Labor.  DC.  ATTN:  Manpower  Admin 
1  US  Dept  of  Justice,  DC,  ATTN:  Drug  Enforce  Admin 
1  Nat  Bur  of  Standards.  DC.  ATTN:  Computer  Info  Section 
1  Nat  Clearing  House  for  MH  Info.  Rockville 
1  Denver  Federal  Ctr,  Lakewood,  ATTN:  BLM 
1 2  Defense  Documentation  Center 

4  Dir  Psych.  Army  Hq,  Russell  Ofcs,  Canberra 

1  Scientific  Advsr,  Mil  Bd,  Army  Hq,  Russell  Ofcs,  Canberra 
1  Mil  and  Air  Attache,  Austrian  Embassy 

1  Centre  d*  Recherche  Des  Facteur s.  Humame  de  la  Defense 
Nationale,  Brussels 

2  Canadian  Joint  Staff  Washington 

1  C/Air  Staff,  Royal  Canadian  AF.  ATTN  Pers  Std  Anal  Br 

3  Chief,  Canadian  Def  Rsch  Staff.  ATTN:  C/CRDS(W) 

4  B"tish  Def  Staff.  British  Embassy,  Washington 


1  D«t  &  Civil  Inst  of  Envuo  Medicine,  Canaria 
1  AIR  CRESS.  Kensington,  ATTN  Info  Sys  B» 

1  Militaerpsykologisk  Tjeneste,  Copenhagen 
1  Military  Attache,  French  Embassy.  ATTN:  Doc  Sec 
1  Mt’decm  Chet,  C  E  RT'  A.  Arsenal.  Touton/Navaf  France 
1  Pi  in  Scientific  0ft,  Appl  Hum  Engl  Rsch  Div,  Ministry 
ol  Defense.  New  Delhi 

1  Pers  Rsch  Ofc  Library.  AKA,  Israel  Defense  Forces 
T  Mimsteris  van  Defensie,  DOOP/KL  Afd  Sooaai 
Psychologische  Zaken.  The  Hague.  Netherlands 
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